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Kernelized  Secure  Operating  System  (KSOS): 

Security  Kernel  Computer  Program  Development  Specification  (Type  B5) 


1.  SCOPE 

1 • 1  Identlt lcatlon 


This  specification  establishes  the  performance,  design,  development  and 
test  requirements  for  the  Kernelized  Secure  Operating  System  (referred  to  as 
"KSOS")  Security  Kernel.  The  KSOS  Security  Kernel  is  intended  to  support  the 
emulation  of  the  UNIX  operating  system  while  providing  an  environment  suitable 
for  the  construction  of  new  secure  systems. 

1*2  Functional  Summary 

The  primary  purpose  of  this  specification  is  to  define  the  functional 
requirements  for  a  Security  Kernel  to  support  the  emulation  of  the  standard  UNIX 
operating  system.  This  specification  further  defines  the  design,  test,  perfor¬ 
mance,  and  quality  assurance  provisions  for  the  KSOS  Security  Kernel. 

This  specification  is  Intended  to  serve  an  additional  purpose,  that  of 
defining  a  particular  implementation  of  the  KSOS  Security  Kernel  on  a  Digital 
Equipment  Corporation  PDP-11 /70  computer  system.  Thus,  there  are  a  number  of 
PDP-11/70  specific  points  throughout  the  specification.  For  implementations  of 
the  KSOS  Kernel  on  other  hardware  bases,  these  points  should  be  treated  as  non- 
binding,  informative  commentary*- - 

The  KSOS  Security  Kernel  shall  support  the  emulation  of  the  standard  UNIX 
operating  system  within  the  constraints  of  the  multilevel  security  model.  The 
Security  Kernel  shall  provide  all  the  data  and  computational  objects  required  to 
construct  a  general  purpose  operating  system.  The  Security  Kernel  shall  mediate 
all  information  exchanges  within  the  system  permitting  only  those  exchanges 
which  are  consistent  with  the  multilevel  security  model.  The  Security  Kernel 
shall  provide  secure  information  channels  which  permit  the  user  to  communicate 
directly  with  "trusted"  software  processes.  The  secure  information  channels 
shall  not  be  subject  to  compromise  due  to  "spoofing"  by  untrusted  software* 

This  specification  is  organized  in  the  following  way.  First  the  relevant 
Kernel  requirements  are  detailed.  The  presentation  of  the  requirements  includes 
the  general  interface  requirements,  interface  block  diagram,  and  the  detailed 
interface  definition.  The  detailed  interface  definition  specifies  the  Security 
Kernel  call  interface  and  significant  Kernel-related  software  elements,  i.e., 
the  scheduler  and  secure  terminal  interface.  System  adaptability  is  discussed 
followed  by  the  specification  of  quality  assurance  provisions  for  the  Security 
Kerne 1 • 

1.3  Terminology 

The  language  used  throughout  this  specification  attempts  to  conform  to  the 
guidelines  of  Section  3.2.3  of  MIL-STD-490.  In  particular,  the  word  "shall" 
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means  that  the  specification  expresses  a  provision  that  is  binding*  The  words 
"should"  and  "may"  mean  that  the  specification  expresses  a  provision  which  is 
non-mandatory.  The  word  "will"  is  used  to  express  a  declaration  of  purpose  on 
the  part  of  the  Government. 

KSOS  shall  support  the  mandatory  DoD  security  policy  of  DoD  Directive 
5200. 1-R  that  is  embodied  in  a  Government  approved  mathematical  model.  [Verif 
78]  Proofs  of  the  system's  security  properties  shall  be  in  terms  of  this  model. 
KSOS  shall  provide  a  minimum  of  eight  (8)  hierarchical  security  classification 
categories  (or  simply  security  categories)  and  a  minimum  of  thirty-two  (32) 
mutually  Independent  security  compartments.  The  security  categories  shall  be 
such  that 


UNCLASSIFIED  <  CONFIDENTIAL  <  SECRET  <  TOP  SECRET 


Where  "<"  is  defined  in  accordance  with  the  requirements  of  DoD  5200. 1-R.  One 
security  compartment  shall  be  reserved  for  read  protection  of  system  data  bases 
and  programs.  This  compartment  shall  be  called  the  "system"  compartment.  KSOS 
sha'  provide  for  Kernel -enforced  integrity.  Integrity  is  defined  as  the  formal 
mathematical  dual  of  security  [Biba  75].  At  least  four  (4)  hierarchical 
integrity  classification  categories  (or  simply  integrity  categories)  shall  be 
provided  in  KSOS.  The  integrity  categories  Include  at  least  the  following  three 
classification  categories: 

USER  <  OPERATOR  <  ADMINISTRATOR 


Although  there  is  no  immediate  requirement  for  integrity  compartments,  the 
development  contractor  should  include  provisions  to  ease  their  later  inclusion. 
For  the  remainder  of  this  specification,  the  term  "security  level"  means  the 
combination  of  a  security  category  and  a  set  of  security  compartments  (which  may 
be  null).  The  term  "integrity  level"  means  the  combination  of  an  integrity 
category,  and  a  (presently  always  null)  set  of  integrity  compartments.  The  term 
"level"  (or  "access  level")  means  the  security  and  integrity  level,  that  is,  the 
combination  of  a  security  category,  a  set  of  security  compartments  (which  may  be 
null),  an  integrity  category,  and  a  (presently  always  null)  set  of  integrity 
compartments.  The  "access  matrix"  defines  for  a  particular  user  or  group  the 
combination  of  the  maximum  security  level  permitted  for  that  user  or  group,  all 
security  compartments  to  which  that  user  or  group  has  access,  the  maximum 
Integrity  level  for  that  user  or  group,  and  all  integrity  compartments 
(presently  always  null)  to  which  that  user  or  group  has  access. 

In  a  secure  system  it  is  necessary  to  have  processes  external  to  the  kernel 
which  perform  security  critical  functions.  These  have  come  to  be  called 
"trusted  processes".  In  KSOS  there  is  a  refinement  in  this  terminology.  As 
Figure  1-1  shows  there  are  subdivisions  of  the  software  inside  the  security  per¬ 
imeter.  Some  of  the  processes  are  "privileged".  This  means  that  they  may 
violate  one  or  more  of  the  security  rules  enforced  by  the  Kernel.  These 
processes  must  be  designed  and  implemented  with  the  same  care  and  thoroughness 
as  the  Kernel  itself.  Section  3. 1.1. 2. 5  presents  the  privileges  which  may  be 
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Figure  1-1.  Terminology  Figure 

afforded  processes.  A  second  subdivision  has  been  termed  "responsible" 
processes.  These  are  processes  are  not  privileged  to  violate  any  of  the 
Kernel's  rules,  but  which  are  nonetheless  Important  to  the  overall  security  of 
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the  system*  Examples  of  responsible  processes  Include  the  Secure  Mail  facility 
and  the  processes  which  manipulate  the  data  bases  describing  the  users'  security 
and  integrity  permissions  (the  "access  matrix").  These  processes  must  also  be 
carefully  designed  and  implemented,  but  do  not  require  formal  specification  or 
verification.  Because  they  do  perform  security-related  functions,  they  cannot 
Include  untrusted  components  (e.g.  the  UNIX  Emulator).  The  third  subdivision  is 
the  "encapsulated  utilities"  (EU  in  the  figure).  These  are  self  contained  func¬ 
tions  to  which  the  user  simply  supplies  parameters.  The  encapsulated  utilities 
are  not  privileged  to  violate  Kernel  rules,  and  do  not  affect  the  security  of 
users.  The  chief  function  in  the  encapsulated  utilities  is  system  generation. 
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2.  APPLICABLE  DOCUMENTS 


The  following  documents,  of  exact  issue  shown,  form  a  part  of  this  specifi¬ 
cation  to  the  extent  specified  herein.  In  the  event  of  a  conflict  between  the 
referenced  documents  and  the  contents  of  this  specification,  this  specification 
shall  be  considered  a  superseding  requirement.  In  the  text  references  to  these 
documents  are  in  the  form  [Name  date],  e.g.  [Blba  75]. 

2. 1  Government  Documents 


2.1.1  Directives.  Manuals  and  Standards 

a.  DoD  5200. 1-R  Information  Security  Program  Regulation 

b.  DoD  5200.28  Security  Requirements  for  Data  Processing  (ADP) 

c.  DoD  5200. 28-M  ADP  Security  Manual 

d.  MIL-STD-483  Configuration  Management 

e.  MIL-STD-490  Specification  Practices 

f.  MIL-STD-1 52 1A  Technical  Reviews  and  Audits 

2.1.2  Reports 

a.  [A-Specs  78]  "KSOS  System  Specification  (Type  A)",  WDL-TR7808  Revision  1, 
Ford  Aerospace  and  Communications  Corporation,  Palo  Alto,  CA  (July  1978). 

b.  [Bell  and  LaPadula  73]  Bell,  D.E.  and  LaPadula,  L.J.,  "Secure  Computer  Sys¬ 
tems",  ESD-TR -73-278,  Volume  I -III,  MITRE  Corporation,  Bedford,  MA 
(November  1973  -  June  1974). 

c.  [Biba  75]  Biba,  K.J.,  "Integrity  Considerations  for  Secure  Computer  Sys¬ 
tems",  MTR-31 53 ,  MITRE  Corporation,  Bedford,  MA  (June  1975). 

d.  [Emulator  78]  "KSOS  Computer  Program  Development  Specification  (Type  B5): 
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3.  REQUIREMENTS 

3* 1  Computer  Program  Definition 

This  Computer  Program  Configuration  Item  (CPCI)  defines  a  provably  secure 
operating  system  kernel  which  enforces  BoD  security  regulations  upon  computer 
computations.  The  initial  implementation  of  the  Security  Kernel  for  KSOS  shall 
execute  upon  a  Digital  Equipment  Corporation  PDP-11 /70  computer  system.  The 
minimum,  typical  and  maximum  hardware  configurations  to  be  supported  by  KSOS  are 
described  in  the  System  Specification  [A-Specs  78]. 

3.1.1  Interface  Requirements 

The  KSOS  Security  Kernel  shall  have  the  following  interfaces  between  major 
system  components: 

a.  between  all  software  elements  and  the  host  computer  hardware; 

b.  between  all  software  executing  in  the  supervisor  and  user  virtual  memory 
domains  of  the  PDP-11/70; 

c.  between  the  Kernel  and  all  privileged  security  related  subsystems  defined 
in  the  Non-Kernel  Security  Related  Software  CPCI  [NKSR  78] . 

d.  between  the  user  terminal  and  the  Security  Kernel. 

All  information  exchanges  between  user  programs,  privileged  subsystems,  files, 
and  devices  shall  be  mediated  by  the  KSOS  Security  Kernel. 

3. 1.1.1  Interface  Block  Diagram 

Figure  3-1  is  the  interface  block  diagram  for  the  KSOS  Security  Kernel. 
This  diagram  illustrates  the  layers  of  virtual  machines  or  functional  capability 
of  KSOS.  The  Security  Kernel  interfaces  directly  with  the  KSOS  UNIX  Emulator 
CPCI,  user  programs,  and  the  host  (PDP-11/70)  computer.  Both  the  Emulator  and 
the  user  programs  shall  communicate  directly  with  the  Kernel  through  an  inter¬ 
domain  call  instruction  such  as  the  PDP-11  EMT  instruction.  To  preserve  compa¬ 
tibility  with  existing  UNIX  applications  on  the  PDP-11 /70,  the  PDP-11  TRAP  and 
IOT  instructions  shall  be  reserved  for  the  emulation  of  the  UNIX  operating  sys¬ 
tem.  The  Security  Kernel  shall  support  secure  communication  paths  from  the  user 
terminal  to  the  trusted  system  software. 


Figure  3-1.  Interface  Diagram 

3. 1.1.2  Detailed  Interface  Definition 

This  section  further  details  the  interfaces  between  the  KSOS  Security  Ker¬ 
nel  and  the  software  elements  listed  in  Section  3.1.1,  Interface  Requirements. 
The  objects  supported  by  the  Kernel  are  discussed,  followed  by  a  presentation  of 
Che  structure  of  processes  executing  on  the  Security  Kernel.  Finally,  these  con¬ 
cepts  are  applied  to  the  detailed  interface  specification  between  the  KSOS  Secu¬ 
rity  Kernel  and  the  other  KSOS  software  elements. 
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3-1-1-2.1  Kernel  Objects 


Five  objects  shall  be  supported  at  the  Kernel  interface:  processes,  process 
segments,  files,  devices  and  subtypes*  The  next  section  discusses  the  five  Ker¬ 
nel  objects  and  the  mechanism  used  to  name  the  objects  and  to  retain  control 
information  concerning  the  object.  This  discussion  is  followed  by  a  presenta¬ 
tion  of  the  Kernel  primitive  operations  upon  these  objects. 

All  -Kernel  objects  shall  be  referenced  by  a  common  designator  called  the 
Secure  Entity  Identifier  (SEID,  pronounced  "seed”).  The  SEID  shall  be  separated 
into  two  parts,  the  name  space  partition  and  the  name  within  the  partition. 
Only  one  object  type  shall  be  assigned  to  each  partition.  However,  more  than 
one  partition  may  have  the  same  type.  The  name  space  partition  shall  be  used  to 
distinguish  the  object  type:  file,  device,  process  segment,  file  subtype,  and 
process.  The  name  space  partition  for  a  file  designates  the  logical  volume 
("extent")  on  which  the  file  resides.  The  System  Administrator  should  make  sure 
that  the  logical  volumes  that  could  be  mounted  on  his  system (s)  have  unique  name 
space  partitions.  The  Immigration  Officer  function  of  the  Non-Kernel  Security 
Related  Software  [NKSR  78]  aids  in  this  task  by  maintaining  a  data  base  of  name 
space  partitions  in  use.  The  name  within  the  partition  shall  be  used  to  specify 
particular  instances  of  an  object  within  the  partition.  A  SEID  shall  be 
returned  as  the  result  of  new  object  creations  (i.e.  K_create,  K_build_segment , 
K_fork,  and  R_spawn.) 

Associated  with  each  Kernel  object  are  two  classes  of  information: 

a.  type  Independent  information:  information  common  to  all  objects.  The  type 
independent  information  includes: 

1.  the  security  level  of  the  object  (Classification  category  and  compart¬ 
ment  set) 

2.  the  integrity  level  of  the  object  (classification  category  and  com¬ 
partment  set) 

3.  the  discretionary  access  control  information.  As  in  UNIX,  this  infor¬ 
mation  shall  consist  of  three  sets  of  permissions: 

♦  for  processes  with  the  same  user  ID  as  the  object  (in  UNIX  "the 
owner") , 

♦  for  processes  with  different  user  IDs,  but  the  same  group  ID 
("the  group") ,  and 

♦  for  processes  with  both  different  user  IDs  and  group  IDs  ("all 
others") . 

Each  permission  shall  consist  of  three  Independent  access  modes: 

♦  read. 


•*  write,  and 
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♦  execute /search • 

4.  the  object's  owner  (a  user  ID  and  a  group  ID) 

5.  the  set  of  privileges  associated  with  the  object* 

b*  the  type  dependent  Information:  Information  whose  content  varies  by  the 
type  of  the  object 

The  type  independent  Information  for  an  object  contains  all  of  the  Informa¬ 
tion  required  by  the  Kernel  to  make  security  decisions  (l.e*  to  permit  or  deny 
an  access  attempt  by  a  process  to  an  object)*  Because  the  type  independent 
Information  is  the  same  for  all  objects,  the  security  checking  may  be  Imple¬ 
mented  more  simply.  As  is  shown  In  the  formal  specifications  for  the  Kernel 
(Appendix  A  to  this  specification),  all  mandatory  access  checking  can  be  local¬ 
ized  in  a  single  function,  SMXflow,  which  checks  whether  Information  may  legiti¬ 
mately  flow  from  the  requested  source  to  the  requested  destination* 

The  discretionary  access  checking  can  be  similarly  localized  in  a  single 
function,  SMXdap.  The  Kernel  shall  normally  enforce  only  the  read  and  write 
permissions.  However,  some  processes  possess  the  privilege  to  use  the 
execute /search  permissions  for  read  permission  ("realize  execute  permissions''). 
This  privilege  Is  used  to  faithfully  emulate  UNIX  execute-only  flies  (by  the 
Process  Bootstrapper  CPC)  or  search-only  directories  (by  the  Directory  Manager 
CPC). 

3. 1.1.2. 1.1  Kernel  Object:  Processes 

In  KSOS  the  process  Is  the  only  active  agent  In  the  system.  All  the  other 
Kernel-supported  objects  are  passive.  The  type  Independent  Information  for  the 
process  and  for  the  object  being  accessed  shall  be  used  by  the  Kernel  to  deter¬ 
mine  whether  to  permit  or  deny  access  attempts  by  the  process.  A  process  shall 
have  two  owner  identifications:  the  effective  owner  (user  ID  and  group  ID)  and 
the  real  owner.  The  effective  owner  shall  be  used  In  discretionary  access 
checking,  and  shall  be  Inherited  by  new  objects  created  by  this  process.  Thus 
the  effective  owner  Is  part  of  the  type  Independent  Information.  The  real  owner 
Is  part  of  the  type  dependent  Information  for  the  process. 

Because  a  process  is  itself  an  object,  the  Kernel  shall  enforce  the  manda¬ 
tory  and  discretionary  access  policies  on  accesses  to  the  process.  In  particu¬ 
lar,  Interprocess  communication  (IPC)  shall  only  be  permitted  If  Information  may 
flow  from  the  sending  process  to  the  recipient. 

The  type  dependent  information  for  a  process  shall  include: 

a.  the  Identities  (SEIDs)  of  this  process  and  Its  parent  process  (the  parent 
process  Is  the  process  which  brought  this  one  Into  existence  via  a  K_fork 
or  a  K_spawn  Kernel  call) 

b.  the  process  family  name 

c.  the  real  owner  (user  ID  and  group  ID) 
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d.  the  program  counter  (pc)  (PDP-11  specific) 

e.  the  program  status  word  (ps)  (PDP-11  specific) 
f«  the  pseudo  Interrupt  level 

g.  the  advisory  priority 

h.  the  timer  alarm  value  (causes  a  pseudo  interrupt  when  It  counts  down  to 
zero) 

I.  the  supervisor  mode  execution  time  (PDP-11  specific) 

J.  the  user  mode  execution  time 

k.  the  timer  toggle  TRUE  ->  pseudo  Interrupt  every  clock  tick  FALSE  “>  no 
Interrupt 

In  order  to  provide  an  operationally  viable  system,  the  Kernel  shall  pro¬ 
vide  support  for  privileged  processes.  Privileged  processes  shall  be  either 
created  at  system  Initialization  or  become  privileged  through  the  execution  of 
the  Kernel  calls  K_invoke  or  K_spawn  specifying  that  a  privileged  Instruction 
segment  Is  to  replace  the  segments  of  the  process.  The  privileges  of  a  process 
shall  persist  until  another  K_lnvoke  is  Issued  by  the  process,  at  which  time  the 
new  privileges  are  established  (R_lnvoke  can  also  remove  any  special  privileges 
for  the  process)  or  until  a  suitably  privileged  process  explicitly  alters  them 
through  a  K_set_ob ject_level  call.  The  privileges  that  may  be  granted  to  a  pro¬ 
cess  are  described  In  3, 1,1,2, 5, 

The  UNIX  Emulator  (Emulator  78]  (with  the  exception  of  the  Directory 
Manager)  and  all  UNIX  user  domain  programs  shall  have  no  special  privileges* 
Thus,  the  Emulator  may  be  modified  by  KSOS  sites  to  provide  locally  desired  UNIX 
calls.  Naturally,  care  must  be  taken  in  such  modifications  so  that  the 
remainder  of  the  UNIX  Interface  provided  by  the  Emulator  Is  unaffected.  How¬ 
ever,  such  changes  cannot  affect  the  security  properties  of  the  system,  because 
the  Emulator  Is  not  "trusted”  by  the  Kernel,  and  cannot  violate  any  of  the  secu¬ 
rity  rules  of  the  system. 

All  privileged  software  shall  communicate  directly  with  the  Kernel,  That 
Is,  such  software  shall  use  the  Kernel  calls  directly  and  shall  not  use  the 
(untrusted)  UNIX  Emulator.  If  privileged  software  Is  modified.  It  must  be  sub¬ 
ject  to  the  same  rigor  (e.g.  formal  specification,  etc,)  that  were  employed  In 
Its  Initial  creation.  Thus,  most  KSOS  sites  will  not  be  allowed  to  modify  or 
create  privileged  software. 

To  the  KSOS  Kernel,  a  process  shall  occupy  multiple,  separate  virtual 
memory  domains.  In  the  PDP-11/70  KSOS  implementation,  a  process  shall  be  com¬ 
posed  of  three  parts: 

a.  User  domain  process  segments 

b.  Supervisor  domain  process  segments 
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c.  Processor  state  (registers,  etc.) 

These  Kernel  objects  shall  be  visible  to  programs  operating  within  the  supervi¬ 
sor  and  user  domains.  The  process  may  also  request  the  Kernel  to  set  or  get  its 
type  independent  and  type  dependent  information  via  the  appropriate  Kernel 
calls. 

3. 1.1.2. 1.2  Kernel  Object:  Process  Segments 

A  process  segment  shall  be  a  portion  of  the  virtual  memory  of  a  process.  A 
process  shall  be  capable  of  having  a  subset  of  its  active  segments  actually 
mapped  into  its  virtual  address  spaces.  Process  segments  shall  be  variable 
sized.  A  single  segment  shall  be  capable  of  spanning  a  virtual  address  range 
from  a  hardware  limited  lower  bound  up  to  the  entire  virtual  address  space  in  a 
domain.  ,  The  development  contractor  may  elect  to  provide  segments  in  only  a 
pre-defined  set  of  sizes.  All  process  segments,  regardless  of  domain,  shall  be 
manipulated  by  the  same  set  of  Kernel  segment  primitives.  User  domain  segments 
shall  be  directly  addressable  to  the  Emulator  (e.g.  through  the  PDP-11 /70 
MFPI(D)  instructions)  in  order  to  transfer  operating  system  call  arguments. 
Programs  executing  in  the  user  domain  shall  not  directly  observe  or  modify  the 
supervisor  domain.  User  and  supervisor  programs  shall  not  directly  observe  or 
modify  Kernel  memory.  In  the  general,  machine  independent  case,  domains  or 
higher  privilege  shall  be  able  to  observe  and  to  modify  domains  of  lesser 
privilege.  Domains  of  lesser  privilege  shall  not  have  any  access  rights  to 
domains  of  greater  privilege. 

Like  the  other  Kernel  objects,  each  segment  shall  have  type  independent 
information  associated  with  it.  This  information  is  used  by  the  Kernel  to  medi¬ 
ate  access  attempts  to  the  segment.  Specifically,  the  Kernel  shall  use  the  type 
independent  Information  in  determining  whether  other  processes  may  map  the  seg¬ 
ment  into  their  virtual  address  space  and  in  setting  up  the  hardware  memory 
mapping/protection  registers  for  the  processes  permitted  access  to  the  segment. 
The  privileges  contained  in  the  segment's  type  independent  information  shall  be 
used  by  the  K_jLnvoke  and  K_spawn  mechanisms.  The  process  privileges  shall  be 
set  from  the  privileges  of  the  intermediary  specified  in  the  call.  The  type 
dependent  information  for  segments  shall  include  the  following: 

a.  Sharable  I  Non-Sharable  (This  information  supplements  the  discretionary 
access  information.  A  segment  might  be  marked  as  readable  and  writable  by 
its  owner,  but  still  not  be  sharable  to  other  processes  with  the  same 
owner,  for  example  the  data  segments  of  a  process.) 

b.  Swappable  |  Locked  in  physical  memory. 

c.  Status  when  the  reference  count  drops  to  0  (destroy  segment Isave  segment) 
(the  UNIX  "sticky  bit",  ISVTXT) 

d.  Direction  of  segment  growth  (upward  |  downward) 

e.  Advisory  position  for  the  segment  when  primary  memory  resident 

f.  Executable  |  Not  Executable  (This  is  more  generic.  In  the  PDP-11 /70  case, 
the  segments  placed  in  data  space  may  be  executable  also.) 
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g.  the  direction  of  growth  for  the  segment  (Up  |  Down) 

h.  the  segment  size 

This  information  and  the  type  independent  Information  for  the  segment  shall  be 
used  by  the  Kernel  in  determining  whether  to  permit  or  deny  attempts  by 
processes  to  access  the  segment  (map  it  into  their  address  space)*  For  permit¬ 
ted  accesses,  this  information  shall  be  part  of  the  information  used  to  set  up 
hardware  protection  and/or  memory  management  registers  for  processes  mapping  the 
segment  into  one  of  their  virtual  address  domains.  For  each  process  mapping  the 

segment  into  one  of  its  virtual  address  domains,  that  use  of  the  segment  shall 

have  associated  with  it: 

a.  the  domain  into  which  the  segment  may  be  mapped 

b-  the  virtual  address  in  that  domain  at  which  the  segment  starts 

c.  whether  the  segment  resides  in  the  Instruction  or  Data  spaces  (for  ihe 

PDP-11 /70  implementation.) 

d.  whether  the  segment  is  presently  active  (mapped  into  the  virtual  address 
space) 

These  attributes  shall  control  the  use  of  the  physical  memory  allocated  to  the 
segment.  This  information  may  be  returned  with  the  other  type  dependent  infor¬ 
mation  about  the  segment* 

The  concept  of  KSOS  process  segments  is  intended  to  be  machine  independent. 
No  assumptions  are  made  about  the  allocation  or  use  of  the  native  memory  manage¬ 
ment  hardware.  Only  two  effects  of  the  underlying  hardware  shall  be  visible  to 
the  Kernel  user: 

a.  When  a  segment  is  allocated,  a  new  mapping  reglster(s)  shall  be  allocated 
in  a  manner  such  that  all  segments  shall  be  individually  mapped  and 
unmapped  from  the  physical  segmentation  hardware. 

b.  Attempts  to  map  a  segment  into  a  process  virtual  address  domain  shall  fail 
when  the  pool  of  available  memory  management  resources  (i.e.,  registers)  or 
virtual  memory  space  has  been  exhausted  or  when  there  would  be  overlap  of 
the  virtual  memory  spaces  of  two  segments. 

The  intent  of  this  approach  is  to  maintain  a  high  degree  of  machine  indepen¬ 
dence. 

In  the  PDP-11 /70  implementation  of  KSOS  as  many  as  sixteen  memory  manage¬ 
ment  registers  shall  be  available  for  segment  mapping  per  process  domain  memory 
space.  If  the  Instruction  and  Data  (I  and  D)  space  separation  feature  of  the 
PDP-11 /70  hardware  is  not  utilized,  only  eight  registers  shall  be  available  to  a 
process  within  a  domain.  The  maximum  length  of  a  memory  vector  supported  by  a 
PDP-11 ,70  map  register  is  4096  words.  In  order  to  create  process  segments  that 
are  longer  than  4096  words,  more  than  one  memory  management  register  shall  be 
used.  (It  should  be  recognized  that  in  order  to  span  the  maximum  virtual  memory 
of  the  PDP-11/70,  segments  must  be  an  integral  multiple  of  4096  words  and  must 
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be  aligned  on  4096  word  boundaries.)  The  ultimate  size  of  a  RSOS  process  will  be 
limited  by  the  addressing  capability  of  the  PDP-11/70;  64K  words  if  I  and  D 
separation  is  enabled,  32K  words  if  it  is  disabled.  Standard  UNIX  process  seg¬ 
ments  can  be  emulated  by  the  following  combinations  of  attributes: 

a.  Program  pure  text: 

1.  Separated  (in  UNIX,  a  "411  magic'  number"):  Sharable,  swappable, 

upward  growing,  instruction  space  placement,  executable,  read  only 

2.  Non-separated  (in  UNIX  a  "410"):  Sharable,  swappable,  upward  growing, 
data  space  placement,  executable,  read  only 

b.  Data,  BSS  and  impure  text:  Non-Sharable ,  swappable,  upward  growing,  data 
space  placement.  Non-executable,  read/write 

c.  Stack:  Non-Sharable,  swappable,  downward  growing,  data  space  placement, 
Non-Executable,  read/write  (In  addition,  UNIX  conventionally  starts  the 
stack  at  the  highest  virtual  address  and  expands  it  downward.) 

d.  IPC  segments:  Sharable,  swappable,  upward  growing,  data  space  placement - 
Non-Executable,  read /write  (or  read-only) 

Other  combinations  would  be  possible.  For  example,  it  may  be  possible  to  imple¬ 
ment  multiple  shared  text  segments,  permitting  the  construction  of  the  common 
Subroutine  mechanic  as  suggested  in  the  proposals  for  UNIX  IPC  [Holmgren  et  al. 
77)  [Nemeth  et  al.  77]  [Sunshine  77]  [Zucker  77].  Existing  UNIX  programs  which 
do  not  use  shared  IPC  segments  shall  find  the  KSOS  process  segment  limitations 
Identical  to  those  of  standard  UNIX. 

3. 1.1.2. I. 3  Kernel  Object:  Files 

The  file  system  visible  at  the  Kernel  interface  shall  be  a  "flat"  file  sys¬ 
tem.  No  structure  shall  be  imposed  upon  the  organization  of  files.  File  direc¬ 
tories  will  be  supported  by  the  UNIX  Emulator  and  the  Directory  Manager.  Hence, 
the  file  objects  at  the  Kernel  level  shall  be  homogeneous.  The  Kernel  files  may 

be  thought  of  as  linear  sequences  of  data  blocks.  The  Kernel  shall  place  no 

special  interpretation  on  the  contents  or  format  of  the  files,  e.g.  there  is  no 
Kernel  support  for  more  sophisticated  access  methods. 

The  type  dependent  information  associated  with  a  file  shall  include: 

a.  the  size  of  the  file 

b.  the  link  count  for  the  file 

c.  the  time  of  the  last  modification  to  the  file 

d.  the  subtype  (if  any)  to  which  the  file  belongs 

e.  whether  or  not  the  file  is  open  for  writing  (or  was  open  when  the  system 
halted) 


Version  4.4 


14 


WDL-TR7932 


Security  Kernel  B5  Specification 


A  process  shall  be  able  to  access  the  file  data  contents  only  if  the  multilevel 
security/integrity  conditions  are  satisfied  and  both  the  file  subtype  and  file 
discretionary  permissions  given  to  the  effective  group  and  user  ID  of  process 
properly  match  the  requested  file  operation. 

Files  shall  be  referenced  at  the  Kernel  level  through  the  use  of  the  Secure 
Entity  Identifier  (SEID)  that  uniquely  Identifies  the  file.  Access  to  a  file 
shall  be  granted  by  the  Kernel  before  any  input  or  output  may  be  performed  to 
the  file.  The  operation  of  opening  a  file  shall  return  an  open  object  descrip¬ 
tor  in  a  manner  similar  to  the  current  Standard  UNIX  file  open.  The  open  object 
descriptor  shall  be  used  to  reference  the  file  in  all  subsequent  Kernel  calls. 
(The  operation  of  opening  a  file  may  be  viewed  as  being  equivalent  to  granting  a 
capability  to  the  data  object  in  a  capability  based  Kernel.) 

3. 1.1.2. 1.4  Kernel  Object:  Devices 

As  in  UNIX,  in  KSOS  devices  may  be  thought  of  as  a  special  class  of  files. 
The  type  dependent  information  for  devices  shall  be  include  the  same  information 
as  the  type  independent  information  for  files.  The  type  dependent  information 
for  devices  may  include  additional  information  used  internally  by  the  Kernel. 
Devices  SEIDs  shall  be  permanently  assigned  in  the  Kernel.  However,  any  UNIX 
directory  entry  may  point  to  a  device.  Because  the  underlying  devices  upon 
which  the  file  system  is  built  are  visible  at  the  Kernel  interface  (i.e.  they 
may  be  opened  by  suitably  authorized  processes),  the  System  Administrator  should 
assure  that  these  devices  are  protected  from  unauthorized  modification  or  access 
by  means  of  appropriate  discretionary  access  and  subtype  membership.  The  Kernel 
shall  not  allow  files  to  be  created  whose  security  level  is  greater  than  the 
underlying  device  on  which  they  are  being  created. 

3. 1.1. 2. 1.5  Kernel  Object:  File  Subtypes 

File  subtypes  are  a  type  extension  feature.  The  goals  of  the  KSOS  Security 
Kernel  file  subtype  mechanism  are  to: 

a.  Subdivide  the  Kernel  file  object  type 

b.  Provide  a  separate  subtype  manager  for  each  file  subtype  controlling  the 

use  of  specially  typed  files  (e.g.  directories) 

c.  Localize  subtype  management  improving  leverage  on  the  proof  process 

File  subtypes,  because  they  are  Kernel  objects,  shall  have  both  a  Secure  Entity 
Identifier  (SEID)  and  a  type  independent  information.  Thus,  file  subtypes  shall 
have  a  security  and  Integrity  level  associated  with  each  Instance  of  a  subtype. 
Most  importantly,  file  subtypes  shall  have  an  owner  and  a  discretionary  permis¬ 
sion  list.  The  subtype  owner  shall  refer  to  the  group  and  user  ID  of  the  subtype 
manager.  The  discretionary  permission  list  shall  describe  the  permitted  access 
modes  to  all  files  of  that  subtype  by  the  subtype  manager  (owner),  group,  and 
all  users. 

The  nature  and  structure  of  file  subtypes  is  best  revealed  by  examining 
their  use  in  the  Kernel  level  file  open  function,  K_open.  In  order  to  open  a 
file  for  access  in  a  specific  mode,  the  process  shall  successfully  meet  four 
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Classes  o£  conditions: 

a.  Mandatory  security  and  integrity 

b.  Subtype  capability  or  file  subtype  discretionary  permission 

c.  File  data  discretionary  permission 

The  subtype  capability  of  a  process  may  be  either  implicit  or  explicit.  Impli¬ 
cit  subtype  capability  shall  be  determined  by  the  effective  group  and  user  ID  of 
Che  process.  If  the  requested  access  mode  successfully  matches  the  permissions 
accorded  to  the  effective  group  and  user  ID  of  the  process  for  that  file  sub- 
type,  the  file  shall  be  opened.  Explicit  subtype  capability  shall  be  acquired 
by  performing  a  K_open  call  on  the  subtype,  specifying  the  subtype  by  Its  SEID. 
Subsequent  K_open  calls  applied  to  files  belonging  to  this  subtype  shall  accept 
the  open  object  descriptor  returned  by  the  subtype  open  operation  as  an  explicit 
capability  (permission)  to  manipulate  the  file  in  the  requested  mode. 

As  an  example  of  the  use  of  rile  subtypes,  thn  Emulator  uses  the  Kernel 
subtype  mechanism  to  implement  UNIX  directories.  Providing  that  they  meec  the 
mandatory  and  discretionary  access  checks,  ordinary  users  are  permitted  r^ad 
access  to  directory  files,  but  are  denied  write  access.  Only  the  Directory 
Manager  is  permitted  to  have  write  access  to  directory  subtype  files.  Htrii-e, 
all  user  processes  are  able  to  search  directories  and  perform  their  own  path 
name  interpretation.  However,  only  the  Directory  Manager  is  able  to  update  or 
delete  directories,  insuring  the  integrity  and  accuracy  of  directory  files. 

3 . 1 . 1 . 2 . 2  Process  Struc cure 


The  logical  information  which  determines  a  specific  instance  of  a  process, 
in  the  PDP-11 /70  impieraentat ion  of  KSOS ,  shall  span  three  memory  domains.  ’rhe 
data  contained  at  each  domain  level  is  characterized  by  the  function  it  is 
intended  to  serve: 

a.  User  domain:  User  process  information  (i.e.,  program  instructions,  data, 
stack,  etc.) 

b.  Supervisor  domain:  Information  required  to  faithfully  emulate  the  UNIX 
operating  system.  Further,  all  Non-Kernel  Security-Related  Software  func¬ 
tions  which  operate  with  special  privileges  or  which  manipulate  security 
critical  data  bases  shall  utilize  only  Kernel  calls  (i.e.  these  functions 
shall  not  utilize  the  Emulator)  and  shall  reside  in  the  Supervisor  domain. 

c.  Kernel:  Process  data  needed  to  multiplex  the  hardware,  maintain  the  logical 
determinacy  of  user  processes,  and  to  enforce  multilevel  security. 

Unprivileged  processes  executing  in  either  user  or  supervisor  domain  shall  be 
regarded  as  "untrusted”  by  the  Kernel  domain  software.  That  is,  the  security, 
integrity,  and  discretionary  access  policies  shall  be  enforced  by  the  Kernel  for 
all  unprivileged  processes. 
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3. I.1.2.3  Hardware  Interface 


The  KSOS  Security  Kernel  shall  execute  correctly  on  all  hardware  configura¬ 
tions  specified  In  the  System  Specification  (Type  A)  [A-Specs  78]. 

The  following  general  remarks  can  be  stated  about  the  KSOS  hardware 
requirements.  The  KSOS  design  shall  execute  on  a  host  computer  with  a  minimum 
of  three  separate  virtual  memory  and  privilege  domains.  The  KSOS  Security  Ker¬ 
nel  shall  reside  in  the  most  privileged  host  processor  domains.  Non-Kernel 
software  shall  reside  in  processor  domains  where  all  accesses  to  Kernel- 
supported  system  resources  can  be  mediated.  This  means  that  non-Kernel  software 
may  not  change  its  virtual  to  physical  address  mapping,  potentially  gaining 
access  to  Information  resident  In  other  processes,  files,  or  device  registers. 
The  processor  shall  also  provide  an  Interdomain  call  mechanism  which  permits 
services  to  be  performed  on  its  behalf  by  software  executing  in  another  virtual 
memory  and  privilege  domain*  That  is,  the  processor  shall  support  some  sort  of 
"trap"  mechanism  for  requesting  services  from  more  privileged  software- 

3. 1.1. 2.4  Emulator/User  Mode  Software  Interface 

In  addition  to  the  mediation  of  information  accesses,  the  purpose  of  the 
KSOS  Security  Kernel  is  to  provide  a  service  environment  to  support  applications 
software  executing  In  Kernel-controlled  processes.  This  specific  implementation 
effort  requires  the  emulation  of  the  Western  Electric  Corp.  UNIX  operating  sys¬ 
tem  interface  as  defined  in  the  System  Specification.  All  non-Kernel  software 
shall  have  a  direct  call  interface  to  the  Security  Kernel.  Hence,  any  non-Kernel 
software  shall  be  able  to  directly  utilize  Kernel  level  services.  Briefly, 
these  Kernel  level  services  are  the  manipulation  of  system  resources,  i.e. 
files,  devices,  processes,  process  segments,  and  file  subtypes.  Section  3.2  of 
this  document  details  the  Security  Kernel  functions  available  through  the  direct 
Kernel  call  interface.  Applications  programs  may  include  both  UNIX  calls  and 
Kernel  calls.  However,  the  application  program  designer  must  take  care  that  the 
use  of  both  types  of  calls  does  not  lead  to  incorrect  results  due  to  interac¬ 
tions  between  the  Emulator's  use  of  Kernel  calls,  and  that  of  the  application 
program.  In  no  cases  can  such  incorrect  interaction  lead  to  security, 
integrity,  or  discretionary  access  violations.  Rather,  the  potential  problem  is 
in  incorrect  results  or  garbling  of  files- 

In  order  to  accurately  emulate  the  UNIX  operating  system  interface  on  the 
PDP-11 /70  host  processor,  the  TRAP  instruction  shall  be  used  to  transfer  user 
domain  requests  to  the  UNIX  Emulator  operating  in  the  supervisor  domain  of  the 
machine.  The  IOT  instruction  shall  also  cause  a  trap  to  the  Emulator  for  the 
invocation  of  core  dumps  by  the  Emulator  at  the  request  of  the  user  domain  pro¬ 
gram.  The  EMT  instruction  shall  be  reserved  for  direct  user  domain  to  Kernel 
and  supervisor  domain  to  Kernel  interdomain  calls.  Parameters  to  Security  Ker¬ 
nel  calls  should  (in  the  PDP-11  implementation)  be  passed  on  the  memory  stack  of 
the  calling  domain.  To  facilitate  the  transfer  of  lengthy  blocks  of  data  (i.e. 
K_device_function,  K_read_block,  and  K_write_block)  an  address  pointer  (called  a 
"parameter  block")  to  the  data  area  may  be  used  as  a  valid  parameter.  The  Kernel 
should  use  this  address  to  fetch/store  information  from  the  data  area-  Return 
values  from  the  Security  Kernel  should  be  transfered  to  the  caller  in  a  register 
(i.e.  register  RO)  where  possible.  When  the  Kernel  is  requested  to  transfer 
data  into  or  out  of  the  user's  memory,  the  data  to  be  transfered  must  be 
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completely  contained  within  one  process  segment.  This  shall  include  the  parame¬ 
ters  passed  in  or  returned  on  the  stack. 

The  KSOS  Security  Kernel  shall  reflect  certain  processor  traps  to  the 
Supervisor  domain  process,  i.e.,  the  UNIX  Emulator.  The  processor  exception 
conditions  reflected  outwards  shall  be  those  traps  caused  by  the  software  exe¬ 
cuting  outside  the  domain  of  the  Kernel.  The  PDP-11/70  traps  to  be  reflected 
outward  by  the  Kernel  are: 

a.  Illegal  or  reserved  instruction  exceptions. 

b.  Breakpoint  traps. 

c.  IOT  instruction  traps.  (Causes  UNIX  abort.) 

ci.  TRAP  instruction.  (Causes  entry  to  UNIX  emulator  dispatch.) 

e.  Floating  point  errors. 

f.  Memory  management  traps. 

The  means  through  which  these  traps  shall  be  communicated  to  the  executing  pro¬ 
cess  shall  be  a  pseudo  interrupt.  The  pseudo  interrupt  may  Include  additional 
information,  such  as  the  cause  of  the  trap,  or  any  relevant  processor  status 
required  by  the  extra-Kernel  software  to  process  the  trap. 

3. 1.1. 2. 5  Privileged  Subsystem  Interfaces 

To  provide  a  useful,  operating  environment,  some  non-Kernel  software  must 
be  privileged  (trusted)  to  perform  system  maintenance  and  other  functions  that 
selectively  violate  the  protection  policy  of  the  Kernel.  The  KSOS  Security  Ker¬ 
nel  shall  maintain  the  process  privilege  information  which  determines  the  poli¬ 
cies  that  the  process  has  been  permitted  to  violate.  Privileged  software  shall 
be  brought  into  execution  either  at  system  initialization  time  or  through  the 
execution  of  the  K_invoke  or  K_spawn  Security  Kernel  primitives.  An  orderly 
system  initialization  procedure  shall  be  implemented  which  initializes  the 
trusted  processes  required  for  correct  operation  of  the  overall  system.  The 
K_invoke  (or  K_spawn)  primitive  shall  derive  the  process  privileges  from  the 
designated  instruction  segment  in  a  manner  which  guarantees  the  execution  of 
that  segment  with  the  privilege  set.  One  particular  instruction  segment,  con¬ 
taining  the  Process  Boo tst rapper  CPC,  shall  have  the  privilege  to  set 
privileges,  and  shall  be  a  mechanism  by  which  a  process  begins  executing  a 
potentially  priviliged  image  contained  in  a  file.  The  Process  Bootstrapper 
shall  set  the  privileges  of  the  process  to  those  of  the  file  from  which  it  was 
initialized.  The  privilege  information  associated  with  the  process  image  file 
is  normally  set  only  by  the  Privilege  Control  Editor  which  may  only  be  executed 
by  the  System  Administrator  or  System  Security  Officer  while  running  at  the 
ADMINISTRATOR  integrity  level.  (See  the  Non-Kernel  Security  Related  Software  B5 
Specification  [NKSR  78].) 

The  following  special  privileges  shc.ll  bo  capable  of  being  granted  or 
revoked: 
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a.  The  ability  to  violate  the  simple  security  property.  (This  privilege  is 
not  presently  used.  It  Is  included  for  completeness.) 

b.  The  at  City  to  violate  the  simple  Integrity  property. 

c.  The  ability  to  violate  the  ^-property  for  security. 

d.  The  ability  to  violate  the  *-property  for  Integrity. 

e.  The  ability  to  violate  the  security  compartment  checking  rules. 

f.  The  ability  to  violate  discretionary  access.  (This  privilege  Is  not  used. 
It  Is  included  for  completeness.) 

g.  The  ability  to  use  the  execute  discretionary  access  permissions  for  read 
access.  (This  Is  also  called  "realize  execute  permissions".) 

h.  The  ability  to  use  the  K_secure_terminal_lock  primitive. 

i.  The  ability  to  use  the  K_link  and  K__unllnk  primitives. 

j.  The  ability  to  use  the  Kjnount  and  K_unmount  primitives. 

k.  The  ability  to  change  the  following  type  independent  information  about  an 
object: . 

1.  The  security  level  of  the  object. 

2.  The  Integrity  level  of  the  object. 

3.  The  the  owner  (user  ID  and  group  ID)  of  the  object. 

l.  The  ability  to  change  the  privileges  In  the  type  independent  information 
for  the  object. 

m.  The  ability  to  set  type  dependent  information  (status)  about  an  file  (i-e., 
the  ability  to  execute  K_set_f ile_status) . 

n.  The  ability  to  save  a  segment  in  the  swapping  area  (l-e.  the  ISVTXT  or 
"sticky  bit"). 

o.  The  ability  to  lock  a  segment  in  core  (not  swappable). 

p.  The  ability  to  use  the  K_signal  primitive. 

q.  The  ability  to  use  the  K_walk_process_table  primitive. 

r.  The  ability  to  use  the  K_halt  primitive. 

s.  The  ability  to  use  the  Kernel  primitives  from  user  mode.  (This  privilege 

is  included  for  protection  of  the  Emulator.  It  shall  be  possible  to  dis¬ 
able  It,  allowing  unrestricted  use  of  Kernel  calls  from  user  domain.) 
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It  should  be  noted  that  the  owner  of  an  object  may  always  change  the  discretion¬ 
ary  access  information  for  that  object,  hence  no  special  privilege  Is  needed. 

There  are  some  privileges  which  subsume  others.  For  example,  the  ability 
to  set  the  level  of  an  object  (change  its  type  independent  information)  is  func¬ 
tionally  equivalent  to  being  able  to  violate  the  simple  security,  security  *- 
property,  simple  integrity,  integrity  *-property,  and  discretionary  access 
rules.  In  general  privileged  processes  should  be  afforded  the  minimum 
privileges  that  allow  them  to  perform  their  intended  functions.  Programs  which 
need  the  more  powerful  privileges,  e.g.  set  object  level,  or  Set  privileges, 
should  be  subject  to  the  most  design  and  implementation  rigor. 

3.1. 1.2.6  Secure  Terminal  Interface 


Certain  privileged  processes  such  as  the  Secure  Server  (part  of  the  Non- 
Kernel  Security-Related  Software  CPCI.  [NKSR  78])  require  a  secure  communication 
path  from  the  user  terminal  to  transfer  passwords  and  other  information  which 
cannot  be  contaminated  or  compromised.  Further,  the  user  must  have  the  assurance 
that  he  is  communicating  solely  with  the  Kernel  or  trusted  subsystem  and  rot  a 
user  process  masquerading  as  a  trusted  program.  The  Secure  Terminal  Interface 
function  of  the  KSOS  Kernel  shall  provide  this  mechanism. 

Two  sets  of  terminal  device  SEID's  shall  be  maintained,  the  user  (thawed) 
set  and  the  Secure  (frozen)  set*  The  user  set  shall  determine  the  access  capa¬ 
bilities  of  regular  user  processes  to  specific  terminals.  The  secure  set  shall 
determine  the  access  capabilities  of  secure  software  to  specific  terminals.  The 
secure  set  shall  be  protected  by  the  discretionary  access  mechanism.  Their 
owner  shall  be  a  distinguished  user  ID,  and  software  allowed  to  use  them  shall 
execute  in  the  discretionary  access  domain  of  this  user  ID.  The  terminal  is 
said  to  be  "frozen"  when  the  secure  path  is  active  and  the  normal  path  is 
blocked.  It  is  said  to  be  "thawed"  when  the  normal  path  is  active.  A  terminal 
shall  become  frozen  when  the  user  enters  the  secure  attention  character,  a  char¬ 
acter  reserved  for  this  one  purpose*  When  the  Kernel  receives  the  secure  atten¬ 
tion  c  laracter  it  shall  freeze  the  terminal  and  send  an  IPC  message  to  th»>- 
Secure  Initiator  [NKSR  78].  A  terminal  shall  become  thawed  only  by  having  a 
privileged  process  issue  a  K_secure_terminal_lock  Kernel  call.  When  a  terminal 
is  frozen,  all  input  and  output  on  the  normal  path  shall  be  blocked.  It  is  the 
responsibility  of  the  processes  privileged  to  thaw  terminals  to  assure  that  only 
the  correct  path  is  thawed,  i.e.  that  the  processes  using  that  path  have  the 
appropriate  security  and  integrity  level  to  use  the  terminal  at  its  (possibly 
new)  level. 

In  the  frozen  mode,  only  software  privileged  to  use  the  secure  path  may 
interact  with  the  user.  (The  exact  privileges  of  such  software  shall  be  the 
privilege  to  use  K_secure_termlnal_lock  and  the  ability  to  execute  in  the  dis¬ 
cretionary  access  domain  user  ID  which  owns  the  secure  terminal  devices.)  In 
order  to  communicate  with  a  frozen  terminal,  a  privileged  process  shall  open  the 
terminal  using  the  corresponding  terminal  SEID  selected  from  the  secure  terminal 
set.  Only  privileged  software  shall  successfully  open  terminals  using  SEID's 
from  the  secure  terminal  set.  The  returned  open  object  descriptor  may  then  be 
used  by  the  secure  process  to  perform  read  and  write  operations  to  and  from  the 
terminal. 
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3 . 2  Detailed  Functional  Requirements 

The  functional  descriptions  in  this  section  use  the  same  argument  names  and 
order  as  the  formal  specifications  found  in  Appendix  A.  However,  these  discre¬ 
tions  have  expanded  out  various  structures  into  their  components  for  clarity  and 
flexibility  of  implementation.  Subject  to  Government  approval,  the  development 
contractor  may  package  the  arguments  as  needed  for  ease  of  implementation  and 
use. 


Many  of  the  following  functions  have  a  list  of  exception  conditions  which 
must  be  satisfied  for  the  function  to  have  any  effect.  The  order  of  these 
exceptions  in  the  text  is  not  necessarily  the  order  in  which  they  should  be 

checked  in  an  implementation  of  the  Kernel.  Rather,  the  order  of  the  exceptions 

in  the  formal  specifications  found  in  Appendix  A  shall  be  used.  The  development 
contractor  may  add  additional  exceptions,  subject  to  Government  approval.  In 

some  cases,  the  true  cause  of  an  exception  cannot  be  returned  to  the  user 

because  it  could  be  used  as  a  confinement  channel  (Lampson  73]  [Lipner  75].  In 
these  cases,  both  the  true  cause  and  the  returned  value  are  noted. 

Some  of  the  functions  utilize  parameter  blocks  to  designate  areas  in  which 
to  accept  or  return  data.  A  parameter  block  is  a  structured  argument  that 
specifies  an  area  of  virtual  memory  for  the  process.  For  the  PDP-11/70  imple¬ 
mentation,  a  parameter  block  shall  consist  of: 

a.  the  domain  in  which  the  data  resides  (user  or  supervisor) 

b.  the  space  in  which  the  data  resides  (instruction  or  data  space) 

c.  the  starting  virtual  address  of  the  data 

d.  the  size  of  the  data  block  (this  may  be  omitted  if  a  standard  size  Is 
always  used) 

In  all  cases,  an  exception  shall  be  raised  if  the  data  area  specified  by  the 
parameter  block  does  not  lie  completely  within  one  segment  which  is  accessible 
to  the  caller.  That  is,  the  segment  containing  the  data  specified  by  the  param¬ 
eter  block  must  be  capable  of  being  accessed  in  the  implied  mode,  For  data  that 
is  being  fetched,  the  segment  must  be  readable,  and  for  data  being  returned,  the 
segment  must  be  writable.  Where  no  ambiguity  results,  the  phrase  "contained  in 
the  parameter  block"  (or  similar)  is  used  in  lieu  of  the  more  precise  "contained 
in  the  data  area  designated  by  the  parameter  block"  in  the  interests  of  brevity. 

3.2.1  Kernel  Function:  K  build  segment 


3. 2. 1. 1  Inputs 

The  Kernel  primitive  K_build_segment  shall  take  the  following  parameters. 

ss .gl. shareable:  Boolean  flag  for  sharing  FALSE  ■>  segment  is  not  sharable, 
TRUE  «>  sharable 

ss.gl.lock:  Boolean  flag  for  locking  TRUE  “>  do  not  swap  (segment  is  locked 
in  memory)  (requires  privilege  to  lock  a  segment)  FALSE  “>  swappable 
ss .gl. sticky :  Boolean  flag  for  segment  status  when  reference  count  goes  to 
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zero  (Lhe  "sticky  bit"  of  UNIX)  TRUE  «>  do  not  destroy  segment 
(requires  privilege  to  set  the  sticky  bit)  FALSE  “>  destroy  Segment 
(normal  case) 

ss .gl.memAdvise:  Boolean  flag  designating  advisory  information  to  the  Kernel 
regarding  placement  of  the  segment  in  memory,  TRUE  ■>  segment  will  have 
I/O  directed  to  it,  FALSE  ■>  no  I/O.  This  is  merely  advisory,  I/O  can 
be  done  to  any  Segment  accessible  in  the  required  mode, 
ss .gl . executable :  Boolean  flag  indicating  whether  this  segment  is  executable 
ss .gl . growth :  the  direction  of  segment  growLh  (up  or  down) 

ss.size:  the  initial  segment  size  in  bytes  (the  development  contractor  may 
round  this  up  to  the  next  integral  unit  of  allocation) 
ss. access:  access  allow  calling  process  to  the  segment 
ss -vl .domain :  domain  of  allocation/mapping 

ss -vl . idSpace :  Instruction  Space  or  Data  Space  placement  (PDP-11/70 
specific) 

ss.vl.vAddr:  virtual  address  of  first  byte  in  the  segment 

ms:  the  initial  discretionary  access  permissions  (read,  write, 

execute /search  for  the  owner,  group,  and  all  others) 


3.2. 1.2  Processing 

K_build_segment  shall  create  a  new  process  segment  and  map  it  into  the  pro¬ 
cess.  Memory  management  registers  shall  be  used  by  the  segment  according  to  the 
address  range  specified  for  the  segment.  An  error  shall  be  returned  if  the 
address  range  specified  for  the  segment  would  be  in  conflict  with  the  address 
range  of  some  other  mapped  in  segment. 

The  discretionary  access  parameter  shall  determine  the  type  of  machine 
reference  permitted  to  the  segment  and  which  other  processes  may  share  the  seg¬ 
ment  if  sharing  is  permitted.  Accesses  shall  be  selected  from  the  set  (read, 
write,  execute).  The  segment  shall  be  initialized  to  contain  all  zeros.  The 
process  must  store  whatever  data  it  requires  into  the  segment  explicitly.  The 
owner  of  the  segment  shall  be  taken  from  the  effective  owner  of  the  process. 
The  security  and  integrity  levels  of  the  segment  shall  be  taken  from  those  of 
the  process. 

Segments  may  be  shared  between  processes  providing  that  the  security, 
integrity  and  discretionary  access  checks  would  allow  such  sharing.  Sharing  of 
segments  requires  that  the  first  process  to  desire  to  share  the  segment  create 
it.  Subsequent  to  creation,  the  segment  SEID  must  be  made  available  to 
processes  wishing  to  share  the  segment,  typically  either  via  placing  it  in  a 
mutually  agreed  upon  file,  or  by  passing  it  via  an  IPC  message.  The  other 
processes  would  then  issue  K_rendezvous_segment  calls  (below)  to  gain  access  to 
the  Segment. 

It  is  the  responsibility  of  the  processes  sharing  the  segment  to  see  to  it 
that  it  is  properly  initialized,  either  by  the  Kernel's  guarantee  of  all  zeros, 
or  by  explicit  initialization.  The  initialization  may  require  cooperation  or 
mutual  exclusion  to  be  completed  successfully.  This  is  particularly  true  in  the 
case  of  shared  pure  text  segments  which  are  to  be  resident  in  the  Instruction 
Space  on  the  PDP-11 /70.  Since  such  segments  cannot  be  written  into,  they  must 
be  created  as  writable  segments,  initialized  from  the  appropriate  image  file. 
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and  then  have  their  status  changed  to  make  them  reside  in  the  correct  space  and 
be  non-writable.  Care  should  be  taken  in  the  design  of  programs  like  the  Pro¬ 
cess  Bootstrapper  which  perform  su-h  initializations  to  assure  that  duplicate 
initialization  attempts  or  multiple  copies  of  the  same  shared  text  segment  do 
not  occur. 

The  virtual  address  and  domain  parameters  shall  be  for  the  calling  process 
only.  Other  processes  sharing  the  segment  may  map  it  into  their  virtual  address 
spaces  as  desired  through  their  use  of  the  K_rendezvous_segment  calls.  Of 
course,  some  segments,  e.g.  text  segments,  may  operate  correctly  only  if  mapped 
starting  at  a  specific  virtual  address. 

3.2. 1.3  Outputs 

The  Kernel  primitive  K_build_segment  shall  return  the  following  informa¬ 
tion. 

ec:  error  conditions 

result. segSeld:  the  seld  of  the  created  segment 

result. segd:  designator  name  (process  local)  of  newly  created  segment 

The  Kernel  primitive  K_build_segment  shall  detect  and  return  the  following 
exception  (error)  conditions. 

EX:  insufficient  privilege,  attempted  to  make  new  segment  either  sticky  or 
locked  in  memory  without  the  appropriate  privilege 

EX:  bad  discretionary  access  mode,  attempted  to  create  a  segment  which  was 
writable  but  not  readable  for  some  permission  (owner,  group  or  other) 

EX:  bad  size,  segment  size  was  too  large 

EX:  global  resource  exhaustion  (this  is  a  potential  channel) 

EX:  too  many  active  segments 

EX:  virtual  memory  error,  virtual  memory  address  space  would  be  exceeded  or 
overlapped,  or  would  fail  to  touch  an  8K  byte  boundary 


3.2.2  Kernel  Function:  K  close 
3. 2. 2. 1  Inputs 

The  Kernel  primitive  K_close  shall  take  the  following  parameters, 
od:  open  object  descriptor 


3. 2. 2. 2  Processing 

The  file  referenced  by  the  K_close  call  shall  be  inaccessible  until  the 
file  has  been  successfully  opened  again.  If  the  object  associated  with  the  open 
descriptor,  od,  is  a  file  whose  link  count  has  been  decremented  to  zero,  and 
there  are  no  other  opens  to  it  (i.e.  po  other  open  descriptors  in  the  system  are 
associated  with  it),  then  the  file  shall  be  deleted  as  part  of  the  K_close  pro¬ 
cessing. 
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3. 2. 2. 3  Outputs 

The  Kernel  primitive  K_close  shall  return  the  following  information, 
ec:  error  condition 

The  Kernel  primitive  K_close  shall  detect  and  return  the  following  exception 
(error)  conditions. 

EX:  open  object  descriptor  does  not  specify  an  open  object 


3.2.3  Kernel  Function:  K  create 
3. 2. 3. 1  Inputs 

The  Kernel  primitive  K_create  shall  take  the  following  parameters. 

nspSeid:  SEID  from  the  name  space  in  which  to  create  file 
ms:  discretionary  access  permissions 

stCap:  subtype  capability,  an  open  descriptor  for  a  subtype.  The  newly 
created  file  will  belong  to  that  subtype  if  the  call  is  successful. 


3. 2. 3. 2  Processing 

K_create  shall  be  the  mechanism  by  which  new  files  are  created.  K_create 
differs  from  the  UNIX  creat(II)  call  in  that  K_create  always  creates  a  new  file. 
R_create  shall  attempt  to  create  the  new  file  in  the  name  space  partition  of  the 
SEID  supplied  as  an  argument.  The  file  control  information  shall  be  allocated 
and  initialized.  The  Kernel  level  file  name  (SEID)  shall  be  returned  for  poten¬ 
tial  inclusion  in  an  Emulator  level  directory  or  similar  construct.  In  addi¬ 
tion,  an  open  object  descriptor  shall  be  returned.  This  shall  be  equivalent  to 
the  user  having  requested  a  K_open  for  writing  on  the  newly  created  file,  with 
the  exception  that  the  discretionary  access  permissions  are  not  checked.  (This 
is  to  allow  the  common  UNIX  construct  of  lock  files  created  with  no  access  per¬ 
missions.)  The  discretionary  access  shall  be  taken  from  the  supplied  argument* 
The  owner  of  the  file  shall  be  taken  from  the  effective  owner  of  the  process. 
The  security  and  integrity  levels  of  the  file  shall  be  taken  from  those  of  the 
process.  The  newly  created  file  shall  belong  to  the  subtype  supplied  via  the 
subtype  open  descriptor,  stCap,  providing  that  stCap  represents  a  valid  subtype 
open  for  writing. 

3. 2. 3. 3  Outputs 

The  Kernel  primitive  K_create  shall  return  the  following  information, 
ec:  error  conditions 

result .fSeid:  secure  entity  identifier 
result. od:  open  object  descriptor 

The  Kernel  primitive  K_create  shall  detect  and  return  the  following  exception 
(error)  conditions. 
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EX:  security/integrity  level  of  file  system  do  not  permit  object  at  this 
level  to  be  created  on  it 
EX:  too  many  open  tiles 

EX:  the  prototype  SEID  supplied  is  not  for  a  file 
EX:  file  system  is  read  only 
EX:  file  system  not  mounted 

EX:  subtype  invalid,  the  subtype  open  descriptor  supplied  was  not  for  a  sub- 
type  open  for  writing 

EX:  unable  to  create  file  (this  is  a  possible  confinement  channel) 


3.2.4  Kernel  Function:  K  device  function 
3. 2. 4. 1  Inputs 

The  Kernel  primitive  K_device_function  shall  take  the  following  parameters. 

od:  open  object  descriptor 
f:  function  requested 

arguments .vloc .domain :  domain  of  parameter  block  containing  input  arguments 
arguments .vloc. idSpace:  space  of  argument  parameter  block 
arguments .vloc .vAddr :  address  of  argument  parameter  block 

arguments .size:  size  of  argument  parameter  block  (may  be  omitted  and  have 
parameter  block  default  to  a  standard  size) 
status. vloc .domain :  domain  of  parameter  block  in  which  status  will  be 
returned 

sta tus .vloc • idSpace:  space  of  status  parametes  block 
status. vloc. vAddr:  address  of  status  parameter  block 

status. size:  size  of  status  parameter  block  (may  be  omitted  and  have  parame¬ 
ter  block  default  to  a  standard  size) 
id:  asynchronous  call  identifier 


3. 2. 4. 2  Processing 

The  K_device_f unction  primitive  shall  permit  the  process  to  perform  special 
device  control  operations.  The  device  shall  be  opened  prior  to  the 
K_device_func tlon  call.  The  device  shall  be  referenced  only  through  an  open 
object  descriptor.  Hence,  authorized  access  to  the  device  shall  always  be 
guaranteed.  In  addition,  the  requesting  process  must  own  the  device.  That  is, 
the  effective  owner  of  the  process  must  be  the  same  as  that  of  the  device,  or 
the  process  must  have  the  privilege  to  change  its  owner.  The  arguments  parame¬ 
ter  block  passed  to  the  K_device_function  call  shall  designate  an  area  of  the 
user  process  memory  which  contains  parameters  required  to  perform  the  specific 
function,  f,  requested.  Thus,  the  particular  parameters  may  vary  depending  upon 
which  function  was  requested.  The  device  specific  routine  shall  be  responsible 
for  verifying  the  validity  of  argument  parameters.  In  particular,  certain  func¬ 
tions  may  require  that  the  process  be  privileged.  The  status  parameter  block 
shall  designate  an  area  of  the  process  virtual  memory  to  be  used  to  return  dev¬ 
ice  specific  status  information.  Thus,  the  particular  parameters  may  vary 
depending  upon  which  function  was  requested. 
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The  access  checking  on  the  two  parameter  blocks  shall  be  similar  to  that 
performed  by  the  K_read_block  call  (below)  for  the  arguments  parameter  block, 
and  to  that  performed  by  K_wrlte_block  (below)  for  the  status  parameter  block. 
Error  returns  from  this  call  shall  include  invalid  file  descriptor  and  handler 
dependent  parameter  value  errors  in  addition  to  the  checks  on  the  validity  of 
the  virtual  addresses  of  the  parameter  blocks,  the  validity  of  the  open  object 
descriptor,  and  that  the  user  owns  the  affected  device. 

Limited  numbers  of  asynchronous  K_device_f unction  requests  may  be  made-  If 
the  the  asynchronous  id  field  is  non-null,  K_device_function  may  return  before 
completion  of  the  requested  operation.  At  the  completion  of  the  requested 
operation,  the  Kernel  shall  transmit  a  device  completion  pseudo  interrupt,  simi¬ 
lar  to  that  transmitted  at  the  completion  of  K_read_block  or  K_write_block.  The 
values  returned  in  the  area  designated  by  the  status  parameter  block  may  not  be 
valid  until  the  pseudo  interrupt  has  been  transmitted. 

3.2. 4. 3  Outputs 

The  Kernel  primitive  K_device_f unc tlon  shall  return  the  following  informa¬ 
tion  . 

ec:  error  conditions 

status:  status  data  in  status  parameter  block 

The  Kernel  primitive  K_device_f unction  shall  detect  and  return  the  following 
exception  (error)  conditions. 

EX:  invalid  open  object  descriptor 

EX:  descriptor  does  not  refer  to  a  device 

EX:  user  does  not  own  device 

EX:  invalid  parameter  block  (either  arguments  or  status) 

EX:  invalid  device  operation  (command) 

EX:  invalid  device  dependent  parameters  in  area  designated  by  arguments 
parameter  block 


3-2.5  Kernel  Function:  K  fork 


3. 2. 5. 1  Inputs 

The  Kernel  primitive  K_fork  shall  take  the  following  parameters. 
None 


3. 2.5.2  Processing 

The  K_fork  primitive  shall  create  a  process.  The  new  process  shall  be 
remembered  as  a  child  of  the  caller  (parent).  The  child  shall  be  an  exact 
duplicate  of  the  parent.  The  process  id  of  the  parent  shall  be  returned  to  the 
child.  The  process  id  of  the  child  shall  be  returned  to  the  parent.  The  pro¬ 
gram  counter  of  the  parent  is  NOT  adjusted  as  it  is  in  standard  UNIX.  The 
returned  process  id  will  be  sufficient  to  distinguish  parent  and  child.  The 
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type  independent  information  of  the  child  process  is  identical  to  the  type 
independent  information  of  the  parent  process* 

The  non-sharable  segments  of  the  process  shall  be  copied  into  new  segment 
instances  for  the  child.  The  reference  counts  of  sharable  segments  shall  be 
incremented*  The  process  local  segment  names  shall  be  the  same  in  both  the 
parent  and  child,  although  in  the  case  of  non-sharable  segments  they  shall  refer 
to  a  different  segment  instance  (and  therefore,  a  different  segment  SE1D)  for 
the  child  than  tor  the  parent. 

The  child  shall  inherit  the  open  objects  of  the  parent*  That  is,  each 
object  that  is  open  in  the  parent  shall  be  opened  in  the  child,  and  shall  have 
the  same  local  open  object  descriptor.  The  open  counts  of  the  open  objects  so 
inherited  shall  be  incremented  to  reflect  the  fact  that  another  process  (the 
child)  has  them  open.  It  the  parent  has  an  object  open  for  exclusive  use,  the 
K_fork  call  shall  fail,  preventing  two  processes  from  having  simultaneous  access 
to  the  same  exclusive  use  object. 

An  error  shall  be  returned  if  the  number  of  available  processes  has  been 
exhausted.  Analysis  will  be  required  to  determine  the  bandwidth  of  this  binary 
information  channel  and  to  select  an  appropriate  solution. 

3. 2. 5. 3  Outputs 


The  Kernel  primitive  K_fork  shall  return  the  following  information. 

childSeid:  process  SEID  (the  parent  gets  childSeid,  and  the  child  gets  the 
process  SEID  of  the  parent) 

ownSeid:  process  SEID  (the  parent  gets  parentSeid,  and  the  child  gets  child¬ 
Seid) 

ec:  error  conditions 

The  Kernel  primitive  K_fork  shall  detect  and  return  the  following  exception 
(error)  conditions. 

EX:  exclusive  use  files  open 

EX:  unable  to  create  new  process  (possible  information  channel) 


3.2.6  Kernel  Function:  K  get  file  status 
3.2.6. 1  Inputs 

The  Kernel  primitive  K get  fllestatus  shall  take  the  following  parameters. 
fSeid:  file  seid 


3. 2. 6. 2  Processing 

K_get_f ile_status  shall  return  the  type  dependent  information  associated 
with  a  file.  The  exact  format  and  information  content  of  the  file  status  block 
shall  be  left  to  the  discretion  of  the  development  contractor  subject  to 
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Government  review  and  approval.  The  invoking  process  must  have  read  access  to 
the  file  with  respect  to  the  manditory  security  and  integrity  rules  only.  No 
discretionary  access  checking  shall  be  performed.  (This  is  required  for  faith¬ 
ful  emulation  of  the  UNIX  construct  of  lock  files  which  are  created  with  no  dis¬ 
cretionary  access  permissions.) 

3.2. 6. 3  Outputs 


The  Kernel  primitive  K_get__f ile_status  shall  return  the  following  informa¬ 
tion. 

ec :  error  conditions 

result .nBiocks :  the  size  ot  the  file  in  blocks 

result . linkCount :  the  number  of  references  to  the  file  in  higher  level  con¬ 
structs  (e.g.  directories  or  equivalent) 
result • timeLastMod :  the  time  of  last  modification  to  the  file 
result. subtype :  the  subtype  to  which  the  file  belongs  (a  SEID) 
result. openForWrit ing:  a  Boolean  flag  indicating  that  this  file  is  open  for 
writing  (TRUE)  or  was  open  for  writing  when  the  system  was  halted.  Such 
information  is  needed  for  higher  order  file  recovery  after  unplanned 
system  halts.  A  value  of  FALSE  shall  mean  that  the  file  had  been  nor¬ 
mally  closed  at  the  time  of  system  shutdown. 

The  Kernel  primitive  K_get_f ile_status  shall  detect  and  return  the  following 
exception  (error)  conditions. 

EX:  object  does  not  exist  or  is  not  a  file,  device  or  subtype 
EX:  attempt  to  read  a  higher  security  level  object  (the  actual  return  value 
is  as  if  the  object  did  not  exist) 

EX:  attempt  to  read  a  lower  integrity  level  object  (the  actual  return  value 
is  as  if  the  object  did  not  exist) 


3.2.7  Kernel  Function:  K  get  object  level 

3. 2. 7. 1  Inputs 

The  Kernel  primitive  K  get  object  level  shall  take  the  following  parame¬ 
ters. 

seid:  the  seid  of  the  desired  object 

3. 2. 7. 2  Processing 

The  primitive  K_get_ob ject_level  shall  return  the  type  independent  informa¬ 
tion  for  an  object. 

3. 2. 7. 3  Outputs 

The  Kernel  primitive  K_get_object_level  shall  return  the  following  informa¬ 
tion. 

ec:  error  conditions 
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otii ■ nd . securityCategory :  security  classification  category  of  object  (e.g. 
TOP  SECRET,  UNCLASSIFIED) 

otii.nd.securityCorap:  security  compartments  of  the  object 
otii.nd.lntegrityCategory :  integrity  classification  category  of  the  object 
ot i i.nd. integri tyCorap :  integrity  compartments  of  the  o'r'e-t  (now,  always 
null) 

otii-da:  discretionary  access  permissions  for  the  object  (read,  write, 
execute/search  for  the  owner,  group  and  others) 
otii. owner:  object  owner  (a  user  ID) 
otli. group:  object  group  (a  group  ID) 
otii.priv:  the  privileges  associated  with  the  object 

The  Kernel  primitive  K_get_ob j ect_level  shall  detect  and  return  the  following 
exception  (error)  conditions. 

EX:  object  does  not  exist 

EX:  attempt  to  read  a  higher  security  level  object  (the  actual  return  value 
is  as  it  the  object  did  not  exist) 

EX:  attempt  to  read  a  lower  integrity  level  object  (the  actual  return  value 
is  as  it  the  object  did  not  exist) 


3.2.8  Kernel  Function:  K  get  process  status 
3 • 2 . 8 . 1  Inputs 

The  Kernel  primitive  K _Jget_process_status  shall  take  the  following  parame¬ 
ters. 

objSeid:  SEID  of  process  about  which  to  get  status 

3. 2. 8. 2  Processing 

The  K_get__process_status  call  shall  return  the  type  dependent  Information 
about  a  process.  A  process  may  successfully  request  information  of  processes 
that  it  can  access  given  its  level  and  the  level  of  the  target  process. 

3.2. 8. 3  Outputs 

The  Kernel  primitive  K _get_process_status  shall  return  the  following  infor¬ 
mation  . 

ec:  error  conditions 

ps.self:  the  SEID  of  the  process  (should  be  the  same  as  objSeid) 
ps • parent:  the  SEID  of  the  parent  process  (The  parent  of  a  process,  p,  is 
the  process  which  issued  the  Kernel  call  that  brought  process  p  into 
existence. ) 

ps. family:  the  process  family  identifier 
ps.realUser:  the  real  user  ID 
ps .realGroup:  the  real  group  ID 
ps.pc:  program  counter  (PDP-11  specific) 
ps.ps:  processor  status  word  (PDP-11  specific) 
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ps.pil:  pseudo-interrupt  level 
ps.advPrio:  advisory  priority 

ps . timerAlarra:  the  time  remaining  before  a  timer  interrupt  will  occur 
ps .supervisorTiming :  execution  time  in  the  supervisor  domain  (PDP-11 
specific)  (This  need  not  be  an  exact  timing.) 
ps .userTiming :  execution  time  in  the  user  domain  (PDP-11  specific) 
ps.timTog:  Boolean  indicating  whether  reptitive  timer  interrupts  are  to  be 
generated 

The  Kernel  primitive  K_get_process_status  shall  detect  and  return  the  following 
exception  (ef  r)  conditions. 

EX:  process  does  not  exist  or  is  inaccessible 


3.2.9  Kernel  Function:  K  get  segment  status 

3 . 2 . 9 . 1  Inputs 

The  Kernel  nrimitive  K  get  segment  status  shall  take  the  following  parame¬ 
ters  . 

SegSeid:  seid  of  the  desired  segment 

3.2.9. 2  Processing 

K_ge t_se gmen t_st a t us  shall  return  the  type  dependent  information  associated 
with  a  segment.  A  process  may  successfully  obtain  type  dependent  status  about 
any  segment  from  which  information  could  flow  to  the  process.  No  discretionary 
access  checking  shall  be  performed. 

3. 2. 9. 3  Outputs 

The  Kernel  primitive  K_get_segment_status  shall  return  the  following  infor¬ 
mation. 

ec:  error  conditions 

ss  .gl.sharable:  Boolean  indicating  whether  or  not  the  segment  may  be  shared 

ss.gl.lock:  Boolean  incicating  whether  or  not  the  segment  is  to  be  locked  in 
memory 

ss .gl . st icky :  Boolean  indicating  whether  or  not  the  segment  is  to  be 
retained  in  the  swap  area  after  there  are  no  more  active  references  to 
it 

ss .gl .meraAdvise :  Boolean  Indicating  whether  or  not  it  is  expected  that  I/O 
will  be  done  to  this  segment  (this  is  merely  advisory,  I/O  can  be  done 
to  any  segment  which  is  accessible  in  the  desired  mode) 

ss.gl. executable:  Boolean  indicating  whether  or  not  the  segment  contains 
executable  data 

ss .gl. direction:  growth  direction  for  the  segment  (Up  or  down)  (PDP-11 
specific) 

ss.size:  the  size  of  the  segment,  in  the  PDP-11  this  is  in  bytes 
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The  Kernel  primitive  K_get_segment_status  shall  detect  and  return  the  following 
exception  (error)  conditions- 

EX:  segment  doesn't  exist  or  is  naccessible 

3-2-10  Kernel  Function:  K  interrupt  return 

3. 2. 10. 1  Inputs 

The  Kernel  primitive  K_interrupt_retum  shall  take  the  following  parame¬ 
ters. 

none 


3.2.10.2  Processing 

K_interrupt_return  shall  provide  an  atomic  return  operation  from  pseudo 
interrupts.  It  can  be  thought  of  as  being  analogous  to  the  PDP-11  RTI  and  RTT 
instructions.  When  a  pseudo-interrupt  occurs,  the  program  counter,  processor 
status  word,  and  current  pseudo-interrupt  level  shall  be  saved  in  a  pseudo¬ 
interrupt  vector  for  the  particular  type  of  pseudo-interrupt  which  occurred.  In 
the  PDP-11  implementation,  these  vectors  shall  be  located  at  fixed  locations  in 
the  supervisor  domain.  The  K_interrupt_return  call  shall  restore  the  process 
itate  from  these  saved  values.  Because  the  interrupted  process  state  is  acces¬ 
sible  to  the  process,  the  K_interrupt_return  call  shall  check  the  saved  state 
prior  to  restoring  it.  The  process  shall  not  be  permitted  to  increase  its 
privileges  or  accessible  domains.  (Similar  checking  takes  place  in  the  process¬ 
ing  of  the  pseudo  interrupt  itself.)  For  example,  in  the  PDP-11  implementation, 
the  process  shall  not  be  allowed  to  set  the  either  mode  (current  or  previous)  to 
kernel  or  to  alter  the  processor  priority  and  general  register  set  information. 

3.2.10.3  Outputs 

The  Kernel  primitive  K_interrupt_retum  shall  return  the  following  informa¬ 
tion. 


none 


3.2.11  Kernel  Function:  K  invoke 
3. 2. 11. 1  Inputs 

The  Kernel  primitive  K_invoke  shall  take  the  following  parameters. 

ImmSeid:  segment  seid  of  intermediary  process  segment 
arg:  segment  designator  specifying  argument  segment 
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3.2.11.2  Processing 

The  purpose  of  the  K_invoke  primitive  is  the  invocation  of  potentially 
privileged  software-  The  effect  of  this  call  shall  be  to  replace  the  existing 
segment  map  (including  the  executing  text  segment)  by  a  new  process  image.  The 
segments  currently  active  may  or  may  not  be  released,  at  the  option  of  the 
development  contractor,  subject  to  Government  approval.  The  new  process  image 
shall  have  only  the  intermediary  segment  and  the  argument  segment  active  (mapped 
in).  Arguments  for  use  by  the  intermediary  process  may  be  placed  in  the  argu¬ 
ment  segment.  The  exact  format  of  the  argument  segment  is  determined  by  the 
particular  intermediary  specified  in  the  call.  The  argument  Segment  may  be  used 
by  the  intermediary  as  a  scratch  pad  as  the  intermediary  builds  any  other  seg¬ 
ments  it  requires.  It  shall  be  the  responsibility  of  the  newly  executing  pro¬ 
gram  (the  intermediary)  to  create  its  own  working  segments.  The  privileges  of 
the  process  shall  be  set  to  those  associated  with  the  intermediary  segment.  In 
the  PDP-11/70  implementation,  the  intermediary  shall  be  mapped  into  location  0 
of  the  supervisor  domain  instruction  space,  and  the  argument  segment  shall  be 
mapped  into  location  0  ot  the  supervisor  mode  data  space.  Thus,  the  iniermeai- 
ary  must  be  coded  as  a  separated  Instruction/data  space  program.  The  intermedi¬ 
ary  may  perform  any  arbitrary  function.  Thus,  applications  of  the  KSOS  Kernel 
may  elect  to  create  specialized  intermediaries  to  perform  specific  runctions. 
The  only  pre-defined  intermediary  is  the  Process  BoctsLrapper ,  described  next. 

3.2.11.3  Process  Bootstrapper  Processing 

The  Process  Bootstrapper  segments  shall  implement  a  trusted  process  whose 
sole  purpose  is  the  creation  of  other,  potentially  trusted,  environments  by 
replacing  itself  with  image  from  the  prototype  file  whose  name  is  passed  in  as 
an  argument.  The  Process  Bootstrapper  shall  have  the  following  privileges: 

a.  to  set  privileges 

b.  to  set  the  effective  owner 

c.  to  set  the  sticky  bit 

d.  to  set  the  lock  (no  swapping)  bit 

e.  to  set  the  security  and  integrity  level 

f.  to  realize  execute  permissions  (i.e.  use  the  execute  permissions  for  read 
access  attempts) 

Using  the  parameters  specified  in  the  argument  segment,  the  Process  Bootstrapper 
shall  build  a  new  set  of  process  segments  conforming  to  the  process  prototype 
file.  The  privileges  for  the  new  environment  shall  be  obtained  from  the  process 
prototype  file.  If  the  prototype  file  has  no  privileges  associated  with  it,  the 
new  environment  shall  be  unprivileged.  If  the  prototype  file  specifies  that  it 
is  to  execute  in  a  different  discretionary  access  domain,  the  bootstrap  shall 
change  the  effective  user  and/or  group  of  the  process  to  the  owner  of  the  proto¬ 
type  file.  The  new  trusted  process  shall  then  be  set  into  execution  by  the  Pro¬ 
cess  Bootstrapper.  Note  that  a  completely  trusted  path  exists  from  the  K_invoke 
call,  through  process  construction,  to  the  execution  of  the  trusted  software. 
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The  use  of  the  K_invoke  call  shall  not  be  limited  to  the  invocation  of 
trusted  processes.  Untrusted  processes  may  also  be  executed  through  the 
K_invoke  call.  If  change  of  discretionary  access  domain  or  privilege  is  not 
required  by  the  type  dependent  information  associated  with  the  process  prototype 
file,  the  process  bootstrap  shall  simply  remove  all  privileges  prior  to  setting 
the  new  image  into  execution. 

The  privilege  information  associated  with  a  process  prototype  file  shall  be 
controlled  by  the  Privilege  Control  Process,  a  restricted  use  program  discussed 
in  the  Non-Kernel  Security-Related  Software  CPCI  Specification  ]NKSR  78]. 

3.2.11.4  Outputs 

The  Kernel  primitive  K_invoke  shall  return  the  following  information, 
ec :  error  conditions 

The  Kernel  primitive  K_invoke  shall  detect  and  return  the  following  exception 
(error)  conditions. 

EX:  invalid  argument  segment  designator 
EX:  argument  segment  is  sharable 
EX:  argument  segment  is  not  writable 

EX:  intermediary  segment  does  not  exist  or  is  inaccessable 
EX:  intermediary  segment  does  not  have  execute  permissions  for  this  user 
EX:  argument  segment  could  not  fit  into  memory  available  to  it 
EX:  intermediary  segment  could  not  fit  into  memory  available  to  it 

The  intermediary  may  detect  additional  error  conditions  associated  with  the  par¬ 
ticular  arguments  supplied.  Due  to  the  fact  that  the  process  environment  is 
discarded  prior  to  the  activation  of  the  intermediary,  these  errors  would  nor¬ 
mally  be  reported  to  the  parent  of  the  process  via  an  IPC  message  from  the 
intermediary.  The  process  bootstrap  shall  report  the  following  exception 
(error)  conditions: 

EX:  prototype  file  is  inaccessible 

EX:  format  of  argument  segment  is  invalid 

EX:  arguments  to  invoked  process  too  large 

3.2.12  Kernel  Function:  K  link 


3. 2. 12. 1  Inputs 

The  Kernel  primitive  Relink  shall  take  the  following  parameters. 
fSeid:  SEID  of  file  affected 


3.2.12.2  Processing 

K_link  shall  increment  the  reference  count  of  a  Kernel  file*  The  reference 
count  may  be  used  to  indicate  the  number  of  UNIX  directory  entries  which  point 
to  this  SEID.  Applications  of  the  KSOS  Kernel  which  do  not  use  the  UNIX 
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directory  structure  and  semantics  may  use  the  reference  count  for  other  pur¬ 
poses.  The  reference  count  may  only  be  incremented  by  processes  privileged  to 
issue  this  call.  Such  processes  should  be  carefully  designed  to  reduce  the 
bandwidth  of  the  resultant  confinement  channels  and  to  preserve  the  integrity  of 
the  higher  level  directory  structure,  if  any.  The  security  and  integrity  check¬ 
ing  on  K_link  shall  be  as  if  the  user  were  reading  and  writing  the  file.  No 
discretionary  access  checking  shall  be  performed.  Thus,  the  processes 
privileged  to  use  K_link  may  implement  whatever  discretionary  checking  they 
chose  to. 


For  example,  the  Directory  Manager  of  the  UNIX  Emulator  [Emulator  78],  when 
emulating  the  UNIX  link(II)  call,  checks  that  the  directory  in  which  the  new 
entry  is  being  place  is  writable  by  this  user  prior  to  making  the  K_link  call. 

3.2.12.3  Outputs 

The  Kernel  primitive  K_link  shall  return  the  following  information, 
ec:  error  conditions 

The  Kernel  primitive  K_link  shall  detect  and  return  the  following  exception 
(error)  conditions. 

EX:  insufficient  privilege 

EX:  object  does  not  exist  or  is  inaccessible  from  security  or  integrity  con¬ 
siderations 

EX:  object  is  not  a  file 

EX:  object  is  in  a  file  system  which  has  been  mounted  as  read  only 

3.2.13  Kernel  Function:  K  mount 
3. 2.13.1  Inputs 

The  Kernel  primitive  K_mount  shall  take  the  following  parameters. 

dev:  device  SEID 

leaf:  file  system  new  SEID 

root:  file  system  old  SEID 

readonly:  Boolean  read  only  flag  TRUE  «>  read  only,  no  writing  is  permitted 
on  the  name  space  partition  being  mounted,  FALSE  »>  writing  allowed 


3.2.13.2  Processing 

The  K_mount  Call  performs  two  functions: 

a.  associating  a  particular  name  space  partition  with  a  device 

b.  causing  all  references  to  the  "leaf  SEID"  to  refer  to  a  SEID  ("root  SEID") 
on  the  newly  mounted  name  space  partition 

In  KSOS,  physical  disk  volumes  may  be  logically  subdivided  into  "extents".  Each 
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extent  containing  a  KSOS  file  system  shall  belong  to  a  different  name  space  par¬ 
tition*  Thus,  the  SEID  of  a  file  is  unique  across  all  the  file  systems  that 
could  be  mounted.  It  shall  be  the  responsibility  of  the  System  Administrator  to 
assure  that  the  name  space  partition  assignment  are  unique.  The  Immigration 
Officer  software  [NKSR  78]  maintains  a  data  base  of  name  space  partitions 
presently  assigned.  When  a  extent  is  mounted,  the  Kernel  shall  update  an  inter¬ 
nal  data  base  that  tells  it  on  which  device  the  SEID's  in  the  mounted  mine  space 
partition  may  be  found.  The  second  facet  of  the  mount  mechanism  is  the  logical 
connection  of  the  newly  mounted  file  system  into  the  rest  of  the  KSOS  file  sys¬ 
tem.  This  shall  be  accomplished  by  mapping  all  references  to  "leaf  SEID",  a 
SEID  of  an  existing,  currently  available  (i.e.  the  old  SEID's  file  system  must 
itself  be  presently  mounted  and  the  leaf  SEID  must  exist  and  be  inactive)  file 
to  a  SEID  on  the  newly  mounted  file  system,  the  "root  SEID".  It  shall  be  possi¬ 
ble  to  mount  a  file  system  as  read  only,  in  which  case  no  writing  may  be  done  to 
any  file  in  that  file  system. 

Each  extent  contains  type  independent  information.  The  security  and 
integrity  levels  of  the  extent  shall  be  interpreted  as  the  maximum  levels 
allowed  for  any  file  on  the  extent.  The  discretionary  access  information  shall 
determine  who  may  mount  that  particular  extent.  To  mount  a  extent  the  user  must 
have  write  permission  to  it.  This  shall  prevent  users  from  mounting  the  private 
extents  of  other  users  or  inactive  system  extents.  The  security  level  and  dis¬ 
cretionary  access  permissions  on  the  devices  shall  determine  who  may  mount  any 
extent  on  that  device.  The  disk  devices  shall  not  be  reserved  only  for  KSOS 
file  systems.  A  given  disk  device  may  be  assigned  for  private,  non-file  system 
use . 


The  following  checks  shall  be  performed  prior  to  performing  the  mount: 

a.  the  process  must  be  privileged  to  issue  the  Call 

b.  the  user  must  own  the  device 

c.  the  user  must  have  write  permission  to  the  extent 

d.  the  security  level  of  the  device  must  be  equal  to  the  security  level  of  the 
extent 

e.  both  the  root  SEID  and  the  leaf  SEID  must  be  files  (although,  normally  they 
would  both  be  of  the  subtype  directory) 

f.  the  leaf  SEID  must  be  inactive  (not  opened) 

g.  the  device  SEID  must  be  a  block  organized  device  (disk) 

h.  the  file  system  must  not  be  presently  mounted 

1.  sufficient  Kernel  mount  table  space  must  exist  (this  is  a  low  bandwidth 
confinement  channel) 

The  Kernel  primitive  K_mount  would  normally  be  called  by  privileged  Non-Kernel 

Security-Related  Software  which  would  make  additional  checks  before  issuing  the 

K  mount  call. 
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3.2.13*3  Outputs 

The  Kernel  primitive  K_mount  shall  return  the  following  information, 
ec:  error  conditions 

The  Kernel  primitive  K_mount  shall  detect  and  return  the  following  exception 
(error)  conditions. 

EX:  insufficient  privilege  level 


EX: 

the  leaf  file  does  not  exist 
integrity  reasons 

or 

Is 

inaccessible 

for 

security  or 

EX: 

the  extent,  dev,  does  not  exist 
integrity  reasons 

or 

is 

inaccessible 

for 

security  or 

EX: 

EX: 

the  leaf  file  cannot  be  written  by 
the  dev  extent  cannot  be  written  by 

this 

this 

user  (discretionary 
user 

access) 

EX:  the  leaf  is  not  a  file 

EX:  the  root  is  not  a  file 

EX:  dev  is  not  an  extent 

EX:  the  extent  is  already  mounted 

EX:  this  user  is  not  the  owner  of  the  extent 

EX:  the  extent  is  open 

EX:  the  leaf  is  open 

EX:  no  more  room  in  the  mount  table 

3.2.14  Kernel  Function:  K  nap 

3.2.14.1  Inputs 

The  Kernel  primitive  K_nap  shall  take  the  following  parameters. 
timeOut:  time  which  should  pass  before  process  should  be  rescheduled 


3.2.14.2  Processing 

K_nap  shall  be  a  mechanism  for  explicitly  giving  up  the  processor  when  a 
higher  level  blocking  condition  occurs.  This  situation  occurs  when,  for  exam¬ 
ple,  processes  implementing  semaphores  on  top  of  the  Kernel  become  logically 
blocked  on  a  semaphore*  K_nap  provides  an  alternative  to  busy  waiting  for  the 
semaphore.  The  timeOut  argument  shall  be  the  incremental  time  before  which  the 
process  should  not  be  rescheduled  by  the  Kernel.  Processes  using  K__nap  should 
check  that  the  logical  condition  for  which  they  were  waiting  has  occurred  when 
they  are  activated. 

3.2.14.3  Outputs 

The  Kernel  primitive  K_nap  shall  return  the  following  information. 
none 

The  Kernel  primitive  K_nap  shall  detect  and  return  the  following  exception 
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(error)  conditions, 
none 


3.2.15  Kernel  Function:  K  open 
3.2.15.1  Inputs 

The  Kernel  primitive  K_open  shall  take  the  following  parameters. 
oSeid:  SEID  of  the  object  to  be  opened 

om:  requested  access  mode  (read,  write,  read  and  write,  write  with  exclusive 
use,  or  read  and  write  with  exclusive  use) 
stCap:  explicit  subtype  capability  (optional,  open  object  descriptor) 


3.2.15.2  Processing 

The  Kernel  open  primitive  shall  be  the  Kernel  analog  of  the  UNIX  user 
interface  open  call.  SEID  interpretation  shall  be  performed  by  the  Kernel.  A 
successful  K_open  call  may  be  thought  of  as  being  equivalent  to  successfully 
granting  the  requested  access  capability  to  the  object*  The  security  and 
integrity  levels  of  the  calling  process  must  permit  the  flow  of  information  to 
or  from  the  object  to  be  opened,  depending  upon  the  open  mode.  For  example,  to 
open  for  reading,  the  security  level  of  the  object  must  be  at  or  below  the  level 

of  the  process-  To  open  for  writing,  the  security  level  of  the  object  must  be 

at  or  above  the  level  of  the  process.  The  caller  shall  have  the  appropriate 
explicit  or  implicit  discretionary  permission  to  the  subtype  of  the  file- 
Explicit  subtype  capability  shall  be  passed  to  the  Kernel  in  the  form  of  an  open 
object  descriptor  returned  from  a  previous,  successful  K_open  on  the  file  sub- 
type  SEID.  Implicit  subtype  capability  shall  be  derived  by  checking  the 
requested  access  mode  against  the  valid  access  modes  permitted  to  the  effective 
group  and  user  ID  of  the  process.  That  is,  if  the  subtype  discretionary  access 

permissions  allow  accesses  in  the  requested  mode,  no  explicit  subtype  capability 

need  be  supplied.  For  example,  if  the  subtype  discretionary  access  permissions 
allow  read  access  by  all  users  and  the  user  is  opening  the  obj  iCt  for  reading, 
the  subtype  capability  need  not  be  supplied.  The  caller  shall  have  the 
appropriate  discretionary  access  permission  to  the  file  as  granted  by  the  owner 
of  the  file.  An  open  object  descriptor  (virtualized  on  a  per  process  basis) 
shall  be  returned  for  subsequent  references  to  the  object. 

The  valid  combinations  of  access  modes  shall  be: 

a.  read 

b.  write 

c.  read  and  write 

d.  write  with  exclusive  use 
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e-  read  and  write  with  exclusive  use 

As  indicated  above,  it  exclusive  use  is  requested,  write  access  must  also  be 
requested.  This  requirement  is  motivated  by  security  considerations. 

Requests  for  open  with  exclusive  use  shall  be  blocking.  (Failure  returns 
from  unsuccessful  exclusive  use  opens  create  clandestine  information  channels.) 
They  shall  remain  blocked  until  the  outstanding  open  on  the  object  has  been 
closed  or  until  a  (system  default)  timeout  expires.  Non-exclusive  use  opens 
shall  also  block  when  attempting  to  open  a  file  with  outstanding  exclusive  use 
access.  The  number  of  files  opened  for  exclusive  use  shall  be  limited  to  one 
per  process  to  prevent  a  class  of  deadlocks.  Exclusive  use  opens  shall  not  be 
passed  to  the  child  process  as  a  result  of  a  fork  operation.  The  fork  shall  fail 
until  the  exclusive  use  file  has  been  closed. 

3.2.15.3  Outputs 

The  Kernel  primitive  K_open  shall  return  the  following  information. 

ec :  error  condition 

od:  open  descriptor  (process  local) 

The  Kernel  primitive  K_open  shall  detect  and  return  the  following  exception 
(error)  conditions. 

EX:  object  does  not  exist,  or  is  inaccessible  from  security  or  integrity 
considerations  . 

EX:  object  link  count  is  zero 

EX:  subtype  capability  that  was  supplied  was  not  for  a  subtype 
EX:  subtype  capability  not  supplied,  but  object  was  in  a  subtype 
EX:  subtype  capability  supplied  was  not  opened  in  the  modes  that  are  being 
requested  for  the  object,  or  was  not  the  same  subtype  as  the  object 
EX:  no  discretionary  access  permission 

EX:  device  on  which  object  resides  has  been  mounted  as  read  only,  and  write 
access  requested 

EX:  exclusive  use  requested,  but  no  write  access  requested 
EX:  another  process  has  the  object  open  for  exclusive  use 

EX:  exclusive  use  requested  and  another  file  already  opened  for  exclusive 
use  by  this  process 

EX:  too  many  open  objects  for  this  process 


3.2.16  Kernel  Function:  K 


3- 2.16.1  Inputs 

The  Kernel  primitive  K_post  shall  take  the  following  parameters, 
receiver:  SEID  of  process  to  which  message  is  to  be  sent 

pseudo Int:  Boolean  flag  TRUE  ■>  cause  pseudo  interrupt  in  receiving  process 
FALSE  *>  no  pseudo  interrupt 

msg:  IPC  message  text  (the  exact  size  of  the  text,  and  whether  this  text  is 
of  fixed  or  varible  size  is  left  to  the  discretion  of  the  development 
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contractor,  subject  to  Government  approval) 


3.2.16.2  Processing 

K_post  shall  send  a  short  message  to  another  process.  A  pseudo  Interrupt 
shall  be  asserted  at  the  destination  process,  if  selected,  and  if  the  receiving 
process  has  IPC  pseudo  interrupts  enabled  (i.e.  that  its  pseudo-interrupt  level 
is  sufficiently  low  to  allow  pseudo  interrupts).  A  header  shall  be  attached  to 
the  message  indicating  the  SEID  of  the  originating  process. 

The  type  independent  information  for  the  two  processes  shall  be  used  to 
determine  rights  of  the  originating  process  to  communicate  with  the  the  destina¬ 
tion. 


3.2.16.3  Outputs 

The  Kernel  primitive  K_post  shall  return  the  following  information, 
ec:  error  conditions 

The  Kernel  primitive  K_post  shall  detect  and  return  the  following  exception 
(error)  conditions. 

EX:  destination  process  does  not  exist  or  is  inaccessible 
EX:  destination  process  cannot  accept  any  more  messages 

Because  the  last  exception  condition  can  be  used  as  an  information  channel,  the 
bandwidth  of  this  channel  shall  be  limited  by  forcing  a  wait  before  return. 

3*2.17  Kernel  Function:  K  read  block 


3.2.17.1  Inputs 

The  Kernel  primitive  K_read_block  shall  take  the  following  parameters, 
od:  open  object  descriptor 

blockNo:  the  logical  block  number  in  the  file  at  which  to  start  reading 
duFile.vloc .domain :  domain  of  block  into  which  the  file  will  be  read 
duFile.vloc • idSpace :  space  of  block 
duFlle.vloc.vAddr:  starting  address  of  the  block 

duFile.size:  length  (in  bytes)  of  the  block,  i.e.,  the  maximum  number  of 
bytes  to  read 

as:  asynchronous  call  identifier 


3.2.17.2  Processing 

K_read_block  shall  retrieve  block(s)  of  data  from  a  previously  opened  file. 
An  error  shall  be  reported  if  the  file  was  not  opened  for  reading.  The  security 
conditions  and  discretionary  access  rights  shall  be  checked  at  the  time  of 
K_open.  Error  and  end  of  file  conditions  shall  be  encoded  into  the  return  value 
from  K_read_block.  Other  errors  shall  include  bad  parameter  values  and  physical 
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I/O  errors. 

Only  block  mode  I/O  shall  be  supported  at  the  Kernel  level.  Stream  I/O  can 
be  Implemented  in  the  UNIX  Emulator  by  caching  the  data  blocks  in  Emulator  level 
buffers.  The  Emulator  would  also  maintain  the  seek  or  file  pointer a-  The  block 
length  parameter  shall  specify  the  maximum  number  of  bytes  to  be  read  from  the 
file  or  device.  This  parameter  value  may  be  device  dependent  and  validity  shall 
be  checked  by  the  specific  device  driver.  Certain  devices,  such  as  terminals, 
can  accept  any  block  length.  For  such  devices,  the  "block"  consists  of  bytes 
from  the  input  stream  up  until  the  occurrence  of  one  of  a  user-controllable  (via 
K_device_funct:ion)  set  of  break  characters  or  until  the  vector  is  full.  The 
Kernel  shall  check  for  the  validity  of  the  vector  in  which  the  data  from  the 
file  is  to  be  placed.  These  checks  include  checking  that  the  vector  is  valid 
and  accessible  (i.e.  can  be  written)  and  that  the  entire  vector  lies  within  one 
Currently  mapped  in  segment. 

The  Kernel  file  system  shall  allow  "sparse”  files,  i.e.  files  in  which  not 
all  blocks  have  been  written  into.  When  one  of  these  unwritten  blocks  is  read 
zeros  shall  be  placed  in  that  part  of  the  returned  data  vector. 

Limited  numbers  of  asynchronous  K_read_block  requests  may  be  made.  If  the 
the  asynchrony  id  field  is  non-null,  K_read_block  may  return  before  completion 
of  the  requested  operation.  At  the  completion  of  the  requested  operation,  the 
Kernel  shall  transmit  an  IP C  message  to  the  requesting  process  containing  (at 
least):  the  SEID  of  device,  the  asynchrony  id,  the  number  of  bytes  read,  and 
other  device  dependent  status  information. 

3.2.17.3  Outputs 


The  Kernel  primitive  R_read_block  shall  return  the  following  information, 
ec:  error  conditions 

ef :  end  of  file.  One  of  the  blocks  requested  was  larger  than  the  number  of 
blocks  in  the  file-  This  condition  may  be  treated  as  an  error  condi¬ 
tion.  All  blocks  that  exist  will  be  returned, 
da:  vector  of  data  In  the  block  (not  an  explicit  return  parameter  in  the 
formal  specifications  In  Appendix  A) 
result. bytesRead:  actual  number  of  bytes  read 

resul t .errst .devlndep :  device  independent  I/O  completion  status 
result .erst .devDep :  device  dependent  I/O  completion  status 

The  Kernel  primitive  K_read_block  shall  detect  and  return  the  following  excep¬ 
tion  (error)  conditions. 

EX:  invalid  open  object  descriptor 

EX:  object  is  a  subtype 

EX:  object  not  opened  for  reading 

EX:  object  is  a  terminal,  and  this  path  is  not  the  current  path 
EX:  size  of  the  request  was  bad  (i.e.  below  minimum,  above  maximum,  or  not 
an  integral  multiple  of  device  dependent  block  size) 

EX:  bad  block  number 
EX:  end  of  file 

EX:  bad  parameter  block  specification  (entire  parameter  block  must  fit 
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within  one  mapped  in  segment  which  can  be  written  into) 


3.2.18  Kernel  Function:  K  receive 


3. 2.18.1  Inputs 


The  Kernel  primitive  K_receive  shall  take  the  following  parameters. 
timeOut:  if  no  messages  have  been  received  within  timeOut,  return 


3.2.18.2  Processing 

K_receive  shall  suspend  the  execution  of  a  process  until  the  receipt  of  an 
IPC  message  or  until  a  time  out.  The  return  value  shall  indicate  the  condition 
which  caused  the  process  to  be  rescheduled. 

The  first  message  in  the  queue  of  received  IPC  messages  shall  be  returned. 
If  the  timeOut  expires  before  any  pseudo-interrupts  occur,  the  error  code  shall 
so  indicate. 

3.2.18.3  Outputs 


The  Kernel  primitive  K_receive  shall  return  the  following  information, 
ec:  error  conditions 

msg. sender:  process  SEID  of  sender  (filled  in  by  the  Kernel) 
msg.text:  data  from  sender 

The  Kernel  primitive  K_receive  shall  detect  and  return  the  following  exception 
(error)  conditions. 

EX:  timeOut  expired  with  no  message  received 


3.2.19  Kernel  Function:  K  release  process 


3. 2.19.1  Inputs 

The  Kernel  primitive  K_release__process  shall  take  the  following  parameters. 
rSeid:  SEID  of  process  to  release  (defaults  to  self) 


3.2.19.2  Processing 

K_release_process  shall  deallocate  all  of  the  Kernel  level  resources  asso¬ 
ciated  with  the  named  process.  Only  a  process  with  the  same  owner  or  a  process 
privileged  to  change  its  owner  may  issue  a  K_release_process  for  another  pro¬ 
cess.  The  effects  of  K_close  for  all  open  files  and  of  a  K_release_segment  for 
all  the  segments  of  the  process  shall  occur.  Shared  segments  shall  remain 
intact  unless  the  reference  count  to  the  segment  has  reached  zero.  Segments 
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with  a  zero  reference  count  shall  be  deallocated  unless  they  have  been  created 
to  be  "sitcky".  Files  shall  be  deallocated  if  their  reference  counts  and  open 
counts  are  zero.  The  process  id  shall  become  unknown. 

3.2.19.3  Outputs 

The  Kernel  primitive  K_release_process  shall  return  the  following  informa¬ 
tion  . 


ec:  error  conditions 

The  Kernel  primitive  K_release_process  shall  detect  and  return  the  following 
exception  (error)  conditions. 

EX:  not  the  owner  of  rSeld  and  no  privilege  to  change  ownership 


3.2.20  Kernel  Function:  K  release  segment 
3.2.20.1  Inputs 

The  Kernel  primitive  K_release_segment  shall  take  the  following  parameters. 
segDes:  segment  name  (process  local  designator) 


3.2.20.2  Processing 

The  primitive  K_release_segment  shall  release  the  Kernel  level  resources 
associated  with  the  specified  segment.  The  segment  shall  not  be  deleted  if 
other  processes  are  still  using  It  or  if  its  sticky  bit  is  set.  An  error  condi¬ 
tion  shall  be  returned  if  the  segment  name  is  unknown  within  the  process. 

3.2.20.3  Outputs 

The  Kernel  primitive  K_reiease_segment  shall  return  the  following  informa¬ 
tion. 

ec:  error  conditions 

The  Kernel  primitive  K_release_segment  shall  detect  and  return  the  following 
exception  (error)  conditions. 

EX:  invalid  segment  designator 


3.2.21  Kernel  Function:  K  remap 
3. 2.21.1  Inputs 

The  Kernel  primitive  K_reraap  shall  take  the  following  parameters, 
in:  designator  name  of  segment  to  be  mapped  in  (may  be  null) 
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vi. domain:  domain  new  segment  to  be  mapped  into 

vl.idSpace:  Instruction  space  of  Data  space  Segment  placement 

vl.vAddr:  virtual  address  within  domain  of  segment 

da:  requested  access  mode  (read,  write,  read  and  write) 

vlFlg:  Boolean  flag  indicating  whether  (TRUE)  or  not  (FALSE)  virtual  loca¬ 
tion  of  this  segment  should  be  changed  in  accordance  with  the  virtual 
location  specified  in  the  call 

daFlg:  Boolean  flag  indicating  whether  or  not  discretionary  access  modes 
should  be  changed 

out:  designator  name  of  segment  to  be  mapped  out  (may  be  null) 
outSlze:  new  size  of  outgoing  segment 

osFlg:  Boolean  indicating  whether  or  not  the  size  of  the  segment  should  be 
changed 


3.2.21.2  Processing 

The  K_remap  primitive  shall  permit  the  process  to  change  its  segment  map. 
The  outgoing  segment  shall  no  longer  be  directly  addressable  by  the  process 
through  machine  instructions.  The  incoming  segment  shall  become  directly 
addressable  by  the  process.  The  outgoing  segment  shall  not  be  released 
(deleted.)  However,  the  memory  management  hardware  of  the  segment  to  be  removed 
from  the  current  mapped  Set  may  be  used  to  satisfy  the  hardware  requirements  of 
the  incoming  Segment.  When  a  process  segment  is  mapped  into  the  current 
addressable  set  of  segments,  it  shall  occupy  the  virtual  address  vector  defined 
by  the  arguments  to  K_remap.  Either  but  not  both  of  the  segment  designators  may 
be  null.  If  both  are  null  the  call  shall  have  no  effects.  The  incoming  segment 
must  fit  into  the  virtual  memory  and  memory  management  resources  available  after 
the  outbound  segment  is  unmapped.  If  it  does  not,  or  if  any  of  the  other  error 
conditions  occur,  the  call  shall  have  no  effect  on  the  segment  mapping. 

If  the  alter  virtual  location  flag  (vlFlg)  is  TRUE,  the  incoming  segment 
shall  be  mapped  into  the  location  specified  as  arguments  to  the  call,  and  its 
status  information  adjusted  to  reflect  this  as  a  permanent  change.  Otherwise, 
the  segment  shall  be  mapped  into  the  location  specified  in  its  permanent  status 
information . 

If  the  alter  discretionary  access  information  flag  (daFlg)  is  TRUE,  the 
modes  in  which  this  process  will  access  the  segment  shall  be  checked  against  the 
permitted  access  modes  for  the  segment,  and  if  allowed,  will  become  the  access 
modes  for  the  segment.  This  may  alter  the  settings  of  memory  management 
hardware  when  the  segment  is  mapped  back  in. 

If  the  alter  size  flag  (osFlg)  is  TRUE,  the  size  of  the  outbound  segment 
shall  be  set  to  the  value  outsize.  The  expansion  or  truncation  of  the  segment 
is  performed  at  the  end  of  segment  specified  by  the  growth  attribute  of  the  seg¬ 
ment  specified  when  built-  Expanded  parts  of  segments  shall  be  filled  with 
zeros.  The  size  change  can  only  be  applied  to  segments  that  are  not  sharable. 

3-2.21.3  Outputs 

The  Kernel  primitive  K_remap  shall  return  the  following  information. 
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ec:  error  conditions 

The  Kernel  primitive  K_remap  shall  detect  and  return  the  following  exception 
(error)  conditions. 

EX:  segment  "in"  is  not  one  of  the  active  segments  for  this  process 
EX:  segment  "out"  is  not  mapped  in 
EX:  segment  "in"  is  already  mapped  in 

EX:  new  segment  discretionary  access  modes  are  for  write  only 
EX:  aterapt  to  change  ths  memory  space  of  a  segment 

EX:  virtual  address  space  overlap  or  insufficient  memory  mapping  hardware  to 
satisfy  request 

EX:  size  change  requested  on  sharable  segment 

EX:  new  discretionary  access  modes  not  allowed  to  this  segment 

3.2.22  Kernel  Function:  K  rendezvous  segment 
3. 2. 22 . 1  Inputs 

The  Kernel  primitive  K_rendezvous_segment  shall  take  the  following  para:ie  - 

ters . 

segSeid:  name  (SEID)  of  segment  with  which  to  rendezvous 

vl. domain:  domain  for  the  Segment,  i.e.  which  domain  the  segment  is  to  be 
mapped  into 

vl.idSpace:  space  for  the  segment 
vl.vAddr:  virtual  address  for  the  segment 
da:  access  type  requested  (read  |  write) 


3*2.22.2  Processing 

The  Kernel  call  K_rendezvous_segment  shall  be  the  mechanism  by  which 
processes  are  able  to  share  segments.  If  the  segment  requested  exists  and  is 
accessible,  it  shall  be  mapped  into  the  processes  address  space  as  requested, 
providing  that  the  requested  mapping  Information  is  valid.  The  Kernel  shall 
check  that  the  segment  may  be  mapped  into  the  process  issuing  the 
K_rendezvous_segment  call.  The  checks  shall  include: 

a.  that  the  segment  seid  is  active 

b.  that  the  segment  may  be  shared 

c.  that  the  security/integrity  level  of  the  process  allows  it  to  access  the 
segment 

d.  that  the  discretionary  access  for  the  segment  allows  it  to  be  accessed  in 
the  requested  way 


that  the  virtual  address  supplied  is  valid 
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3.2.22.3  Outputs 

The  Kernel  primitive  K_rendezvous_segment  shall  return  the  following  infor¬ 
mation. 

ec:  error  conditions 

segd :  process  local  name  f  or  the  Segment 

The  Kernel  primitive  K_rendezvous_segment  shall  detect  and  return  the  following 
exception  (error)  conditions. 

EX:  segment  not  active  or  cannot  be  accessed  from  the  process  security  and 
integrity  level 

EX:  requested  access  mode  was  write  only 
EX:  discretionary  access  denied 

EX:  segment  already  known  to  this  process  (nay  or  may  not  be  mapped  in) 

EX:  virtual  memory  address  space  would  be  exceeded  or  overlapped 
EX:  too  many  segments  for  this  process 


3.2.23  Kernel  Function:  K  secure  terminal  lock 
3.2.23.1  Inputs 

The  Kernel  primitive  R_seCure_termlnal_lock  shall  take  the  following  param¬ 
eters  . 

devSeld :  SE ID  of  terminal  ("desired"  path) 


t. 

I" 


f  ' 


,  ! 


3.2.23.2  Processing 

The  K_secure_terminal_lock  call  shall  provide  a  mechanism  to  control  which 
of  several  paths  to  a  terminal  is  currently  active.  The  call  may  be  success¬ 
fully  invoked  only  by  processes  privileged  to  do  so.  For  each  terminal,  there 
are  several  logical  devices,  one  of  which  is  normally  reserved  for  use  by 
trusted  software  (the  "secure  device").  The  input/output  stream  is  switched 
between  these  logical  devices  by  the  Secure  Server  (part  of  the  Non— Kernel  Secu¬ 
rity  Related  Software).  The  user  may  send  the  secure  attention  character  to  the 
computer*  This  causes  the  Kernel  to  send  an  IPC  message  to  the  distinguished 
process,  the  Secure  Initiator  [NKSR  1978],  and  to  "freeze"  the  terminal  by  ter¬ 
minating  ali  in-progress  operations  on  the  terminal  and  refusing  to  accept  new 
requests  on  any  path  to  the  terminal.  Freezing  means  that  all  paths  are 
blocked;  no  characters  may  be  read  or  written  to  (from)  the  terminal  by  the 
active,  untrusted  processes.  The  secure  attention  character  shall  always  be 
active,  and  shall  be  site  selectable  as  a  system  generation  parameter.  The 
requirement  that  the  secure  attention  character  always  be  active  means  that  the 
setting  of  terminal  speed  and  parity  must  be  performed  by  trusted  software. 

In  the  frozen  state,  no  path  is  active,  but  the  Secure  Initiator  has  been 
informed  of  the  situation.  No  further  action  can  take  place  on  the  terminal 
until  the  trusted  software  causes  a  K_secure_terminal_lock  to  take  place,  thus 
"thawing"  a  path  for  the  use  of  the  Secure  Server. 


Version  4.4 


-  45  - 


WDL-TR7932 


1 


Security  Kernel  B5  Specification 


Now,  only  the  secure  path  is  active,  thus  the  user  can  be  assured  that  he 
(she)  is  communicating  only  with  trusted  software,  and  not  some  untrusted, 
masquerading  process.  Only  the  trusted  software  may  thaw  a  user  pith  (call 
K_seCure_terminal_lock  with  a  SEIO  of  a  user  path  to  the  terminal)  which  then 
deactivates  the  secure  path,  and  unblocks  a  normal  path. 

Each  path  to  a  terminal  shall  have  a  separate  SEID  and  separate  set  of  Type 
Independent  Information.  The  SEIDs  of  a  set  of  paths  to  a  given  terminal  are 
dense;  the  first  SEID  of  a  set  is  designated  the  secure  path.  The  Secure  Server 
may  change  the  level  ot  a  path  by  the  use  of  the  K_set_object_level  function, 
but  only  if  the  path  is  currently  not  open  by  any  process.  Thus  the  tranquility 
property  is  enforced  for  all  paths,  and  it  is  thus  not  possible  for  the  level  of 
a  path  to  change  while  it  is  associated  with  a  process. 

A  unique  exception  status  shall  be  returned  when  a  process  attempts  I/O  on 
a  frozen  path.  It  is  the  responsibility  of  the  process  to  wait  a  short  period 
and  try  again  if  it  wishes  to  wait  for  the  path  to  be  unfrozen  (this  occurs  whn 
the  user  changes  level  at  his  terminal  and  wants  to  leave  a  running  process 
behind ) . 

Because  the  processes  are  not  killed  when  they  are  unable  to  write  to  the 
terminal  at  its  new  level,  it  is  possible  to  return  to  level  later  and  resume  as 
if  nothing  had  happened. 

3.2.23.3  Outputs 

The  Kernel  primitive  K_secure_terminal_lock  shall  return  the  following 
information. 

ec:  error  conditions 

The  Kernel  primitive  K_secure_terrainal_lock  shall  detect  and  return  the  follow- 
ing  exception  (error)  conditions. 

EX:  SEID  does  not  refer  to  a  terminal 

EX:  process  is  not  privileged  to  use  secure  terminal  interface 

EX:  SEID  does  not  exist 


3.2.24  Kernel  Function:  K  set  file  status 


3.2.24.1  Inputs 

The  Kernel  primitive  K_set_file_status  shall  take  the  following  parameters. 

fseid:  seid  of  desired  object 

newStatus -n31ocks :  block  size  of  the  file  (should  not  be  modified  without 
corresponding  alteration  of  any  on-disk  fill  block  allocation  informa¬ 
tion  ) 

newStatus . linkCount :  number  of  references  to  the  file  (used  by  UNIX  Emulatoi 
and  Directory  Manager  to  indicate  number  of  directory  entries  for  the 
file) 

newStatus. timeLastMod :  time  of  the  last  modification  to  the  file 
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newStatus .  subtype :  the  subtype  (if  any)  to  which  the  file  belongs 
newStatus • openAtCrash :  Boolean  flag  indicating  whether  (TRUE)  or  not  (FALSE) 
the  file  is  open  for  writing  or  was  open  when  the  system  halted  (used 
for  recovery  of  higher  level  constructs  like  directories) 


3.2.24.2  Processing 

K_set_f ile_status  shall  set  the  file  object  type  dependent  information. 
This  call  should  be  used  primarily  for  maintenance  functions.  The  intent  is  to 
allow  programs  performing  recovery  and  maintenance  functions  for  higher  level 
constructs,  e.g.  UNIX  directories  to  have  the  ability  to  manipulate  file  status 
information.  Manintenance  and  recovery  of  the  basic  Kernel  file  system  cannot 
be  performed  completely  through  this  call.  Rather,  these  basic  file  system 
recovery  actions  may  require  manipulation  of  the  disk  data  directly.  Naturally, 
such  programs  must  be  designed  and  implemented  with  the  same  thoroughness  and 
techniques  used  for  the  Kernel  implementation,  and  their  use  must  be  restricted 
to  authorized  maintenance  personnel.  The  process  shall  require  the  privilege 
to  set  file  status  to  successfully  use  this  call. 

3.2.24.3  Outputs 

The  Kernel  primitive  K_set_f ile_status  shall  return  the  following  informa¬ 
tion  . 

ec:  error  conditions 

The  Kernel  primitive  K_set_f ile_status  shall  detect  and  return  the  following 
exception  (error)  conditions. 

EX:  either  file  does  not  exist  or  is  inaccessible  from  security  or  integrity 
considerations 

EX:  no  discretionary  access  permissions  to  file 
EX:  not  the  file  owner 

EX:  not  privileged  to  change  file  control  information 


3.2.25  Kernel  Function:  K  set  object  level 
3- 2.25.1  Inputs 

The  Kernel  primitive  K_set_ob ject_level  shall  take  the  following  parame¬ 
ters. 

objseid:  seid  of  desired  object 

level .nd . securityCat :  new  security  classification  category  of  object 
level .nd .securityCorap :  new  security  compartment  set 

level. nd.integritvCat:  new  integrity  classification  category  of  object 
level. nd.integrityComp:  new  integrity  compartment  set  (now  always  null,  may 
be  omitted) 

level. da:  new  discretionary  access  permissions  for  object  (read,  write,  exe¬ 
cute  for  owner,  group  and  others) 
level. owner:  new  owner  for  the  object 
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level-group:  new  group  of  the  object 
level. priv:  new  privileges  for  the  object 


3.2.25.2  Processing 

The  K_set_ob ject_level  primitive  shall  Set  the  type  independent  information 
for  an  object. 

The  owner  of  the  file  shall  be  capable  of  changing  the  discretionary  access 
information.  Processes  with  the  privilege  to  set  object  level  (see  3. 1.1.2. 5) 
shall  be  capable  of  changing: 

a.  the  user  which  owns  the  object 

fc.  the  group  which  owns  the  object 

c-  the  discretionary  permissions 

d.  the  security  level  (security  category  and  compartments) 

e.  the  integrity  level  (integrity  category  and  (presently  null)  compartments.) 

Processes  shall  require  an  additional  privilege  to  set  the  privileges  of  an 
object.  If  the  appropriate  conditions  are  not  met  to  change  the  object 
level/access  information,  only  the  information  which  the  user  is  privileged  to 
change  shall  be  altered. 

3.2.25.3  Outputs 

The  Kernel  primitive  K_set_ob ject_level  shall  return  the  following  informa¬ 
tion. 

ec :  error  conditions 

The  Kernel  primitive  K_set_obj ect_level  shall  detect  and  return  the  following 
exception  (error)  conditions. 

EX:  object  does  not  exist  or  is  inaccessible  due  to  security  or  integrity 
considerat ions 

EX:  insufficient  privilege  to  change  mandatory  access  control  information 
EX:  only  owner  or  privileged  process  can  change  file  owner  or  discretionary 
permissions 

EX:  improper  security  level,  integrity  level,  access  mode,  owner  or  domain 

3.2.26  Kernel  Function:  K  set  process  status 
3. 2. 26. 1  Inputs 

The  Kernel  primitive  K_set_process_status  shall  take  the  following  parame¬ 
ters. 
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procSeid:  SEID  of  process  whose  status  is  to  be  set 

ps.self:  the  SEID  of  the  process  (cannot  be  altered,  included  for  symmetry 
with  K_get_process_status ) 

ps • parenL :  the  SE ID  of  the  parent  process  (cannot  be  altered,  included  for 
symmetry) 

ps- family:  the  process  family  identifier 

ps-realUser:  the  real  user  ID 

ps . realGr oup :  the  real  group  ID 

ps-pc:  program  counter  (PDP-11  specific) 

ps.ps:  processor  status  word  (PDP-11  specific) 

ps-pil:  pseudo-interrupt  level 

ps-advPrio:  advisory  priority 

ps - timerAlar ra:  the  time  remaining  before  a  timer  interrupt  will  occur 
ps • superv isor Timing :  execution  time  in  the  supervisor  domain  (PDP-11 
specific)  (This  need  not  be  an  exact  timing.)  (cannot  be  altered. 
Included  for  symmetry) 

ps -userTiming :  execution  time  in  the  user  domain  (PDP-11  specific)  (cannot 
be  altered,  included  for  symmetry) 

ps-timTog:  Boolean  Indicating  whether  reptitive  timer  interrupts  are  to  be 
generated 


3.2.26.2  Processing 

The  K_set_process_status  call  shall  permit  the  process  to  change  those  type 
dependent  parameters  that  are  not  controlled  by  other  primitives. 

• 

The  K_set_process_status  Kernel  call  shall  supply  an  advisory  scheduling 
priority  to  the  Kernel  level  scheduler-  The  Kernel  may  elect  to  adjust  the 
advisory  priority  to  guarantee  equitable  service  to  all  processes.  Only 
processes  privileged  to  set  privileges  may  alter  their  privileges. 

The  notion  of  real  and  effective  user  identification  shall  be  retained  at 
the  Kernel  level  because  these  identifiers  determine  the  access  permissions 
extended  to  a  process.  The  effective  user  and  group  ID's  are  part  of  the  type 
Independent  information  for  the  process,  because  they  are  what  determine  the 
discretionary  access  rights.  The  real  user  and  group  ID's  are  part  of  this  type 
dependent  information. 

The  timer  toggle  and  pseudo  interrupt  level  control  the  pseudo  interrupt 
mechanism.  If  the  timer  toggle  is  TKUE,  a  pseudo  interrupt  shall  be  generated 
every  clock  tick  (machine  dependent  time  unit).  This  mechanism  may  be  used  for 
periodic  sampling  of  user  mode  program  counter  values  for  the  construction  of 
execution  profiles.  The  pseudo  interrupt  level  is  analogous  to  the  hardware 
interrupt  level.  Pseudo-interrupts  shall  be  transmitted  to  the  process  only  if 
the  level  of  the  pseudo  interrupt  is  above  the  level  of  the  process-  The  pro¬ 
cess  shall  not  be  able  to  raise  the  pseudo  interrupt  level  sufficiently  to 
prevent  hardware  error  pseudo  interrupts. 

3.2.26.3  Outputs 

The  Kernel  primitive  K_set_process_status  shall  return  the  following  infor¬ 
mation  . 
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ec:  error  conditions 

The  Kernel  primitive  K_set__process_status  shall  detect  and  return  the  following 
exception  (error)  conditions. 

EX:  the  process  does  not  exist,  or  is  inaccessible  due  to  security, 
integrity  or  discretionary  access  considerations 


The  Kernel  primitive  K_set_segment_status  shall  take  the  following  parame¬ 
ters  . 

segSeid:  seid  of  the  desired  segment 

st-gl.sharable:  Boolean  indicating  whether  or  not  the  segment  may  be  shared 

st.gl.lock:  Boolean  incicating  whether  or  not  the  segment  is  to  be  locked  in 
memory  (requires  privilege  to  set) 

st .gl. sticky :  Boolean  indicating  whether  or  not  the  segment  is  to  be 
retained  in  the  swap  area  after  there  are  no  more  active  references  to 
it  (requires  privilege  to  set) 

st . gl . memAdv ise :  Boolean  Indicating  whether  or  not  it  is  expected  that  I/O 
will  be  done  to  this  segment  (this  is  merely  advisory,  I/O  can  be  done 
to  any  segment  which  is  accessible  in  the  desired  mode) 

st -gl- executable:  Boolean  Indicating  whether  or  not  the  segment  contains 
executable  data 

st.gl. direction:  growth  direction  for  the  segment  (Up  or  down)  (PDP-11 
specif ic) 

st.size:  the  size  of  the  segment,  in  the  PDP-11  this  is  in  bytes 


3.2.27.2  Processing 


The  Kernel  primitive  K_set_segment_status  supports  modification  of  the  type 
dependent  information  of  a  segment*  The  invoking  process  shall  have  appropriate 
privilege  in  order  to  modify  the  "sticky"  flag  or  the  "lock"  flag. 


3.2.27.3  Outputs 


The  Kernel  primitive  K_set_segment_status  shall  return  the  following  infor¬ 
mation. 


ec:  error  conditions 


The  Kernel  primitive  K_set_segment_status  shall  detect  and  return  the  following 
exception  (error)  conditions. 

EX:  segment  doew  not  exist  or  is  inaccessible  from  security  or  integrity 
considerat ions 

EX:  discretionary  access  violation  (user  must  have  read  and  write  access) 

EX:  segment  is  sharable 


Version  4.4 


-  50  - 


WDL-TR7932 


Security  Kernel  B5  Specification 


EX:  growth  direction  is  different  than  curent  value 
EX:  attempt  to  alter  "sticky"  without  privilege  to  do  so 
EX:  attempt  to  alter  "lock"  without  privilege  to  do  so 


3*2.28  Kernel  Function:  K  signal 


3*2*28.1  Inputs 

The  Kernel  primitive  K_signal  shall  take  the  following  parameters. 

procSeid:  SEID  of  process  to  be  signaled 
sigVal:  value  of  the  signal 


3*2.28.2  Processing 

The  K__signal  primitive  shall  provide  a  means  for  privileged  processes  to 
transmit  a  high  priority  pseudo-interrupt  to  a  process.  K_signal  differs  from 
the  K_post  IPC  mechanism  in  several  ways.  First,  K_signal  always  generates  a 
pseudo  interrupt.  The  pseudo-interrupt  level  of  the  K_signal  pseudo-interrupt 
is  above  that  of  normal  IPC.  Second,  the  K_signal  pseudo  interrupt  will  abort 
long  running  Kernel  calls  (i.e.  terminal  I/O)  which  receiving  the  K__post  mechan¬ 
ism  does  not.  Third,  a  much  smaller  message  is  transmitted.  The  intended  use 
of  K_signal  is  to  provide  a  mechanism  for  a  privileged  process  to  "get  through" 
to  another  process,  typically  to  ask  it  to  terminate. 

3.2.28.3  Outputs 

The  Kernel  primitive  K_signal  shall  return  the  following  information, 
ec:  error  conditions 

The  Kernel  primitive  K_signal  shall  detect  and  return  the  following  exception 
(error)  conditions. 

EX:  process  does  not  have  the  privilege  t-'  issue  the  call 

EX:  either  the  recipient  does  not  exist  or  is  inaccessible  due  to  security 
or  integrity  considerations 
EX:  recipient  pseudo  interrupt  level  too  high 

3.2.29  Kernel  Function:  K  spawn 


3. 2. 29. 1  Inputs 

The  Kernel  primitive  K_spawn  shall  take  the  following  parameters. 

immSeid:  rendezvous  name  or  segment  seid  of  the  intermediary  process  segment 
arg:  segment  designator  specifying  argument  segment 


Version  4.4 


-  51 


WDL-TR7932 


Security  Kernel  B5  Specification 


The  Kernel  primitive  K_spawn  shall  combine  the  functions  of  K_fork  and 
K_lnvoke  into  one  operation.  The  K_spawn  primitive  permits  process  creation 
without  the  cost  of  copying  the  parent  process  image  to  the  child  process.  The 
effect  of  K_spawn  shall  be  to  create  a  new  process  and  to  force  the  effect  of  a 
K_invoke  call  upon  the  newly  created  process.  The  parent  process  may  therefore 
completely  specify  the  contents  of  the  child  process  image. 


The  parameters  to  K_spawn  shall  be  the  same  as  the  parameters  to  the 
K_invoke  primitive.  These  parameters  shall  be  used  to  determine  the  effect  of 
the  K_invoke  call  forced  upon  the  child  process.  (See  K_invoke  above  for  a  dis¬ 
cussion  of  this  primitive.)  The  full  semantics  of  K_invoke  shail  be  implemented. 
Hence,  a  child  process  may  acquire  more  privilege  than  the  parent  and  may 
operate  in  a  different  discretionary  access  domain. 


3.2.29.3  Outputs 


The  Kernel  primitive  K_spawn  shall  return  the  following  information. 


chlldSeid:  SEID  process  identifier  of  the  child  process  (returned  to  parent. 
Child  process  is  returned  the  process  SEID  of  the  parent  process) 
ownSeid:  process  SEID  (parent  gets  parentSeid,  child  gets  chlldSeid) 
ec:  error  conditions 


The  Kernel  primitive  K^spawn  shall  detect  and  return  the  following  exception 
(error)  conditions. 


EX:  unable  to  create  new  process  (See  note  in  "K_fork"  above.) 

EX:  invalid  argument  segment  designator 

EX:  imraediary  segment  does  not  exist  or  is  inaccessible  due  to  security  or 
integrity  considerations 

EX:  discretionary  access  violation  on  intermediary  segment 
EX:  argument  segment  is  not  writable 
EX:  argument  segment  sharable 

EX:  argument  segment  does  not  fit  in  space  allowed 
EX:  intermediary  segment  does  not  fit  in  space  allowed 


The  Kernel  primitive  K_special_function  shall  take  the  following  parame¬ 
ters  . 

fn:  special  function  requested 
parra. domain:  domain  of  parameter  block 
parm.idSpace:  space  of  parameter  block 
parm.vAddr:  address  of  parameter  block 

parm.slze:  size  of  parameter  block  (may  be  omitted  and  default  to  a  standard 
size) 
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3.2.30.2  Processing 

The  K_special_function  primitive  shall  provide  a  convenient  entry  point  to 
request  infrequently  executed  functions.  At  the  discretion  of  the  development 
contractor,  subject  to  Government  approval,  this  primitive  may  be  omitted,  and 
explict  calls  provided  for  each  function  required.  The  major  functions  assigned 
to  K_special_function  are: 

a.  shutdown  processing 

Processes  requesting  shutdown  or  to  Set  the  system  high  security  and  integrity 
levels  shall  have  at  least  OPERATOR  integrity  level.  The  virtual  address  of  the 
parameter  block  shall  be  checked.  The  entire  parameter  block  shall  lie  within 
one  Segment. 

3.2.30.3  Outputs 

The  Kernel  primitive  K_special_function  shall  return  the  following  informa¬ 
tion  . 

ec:  error  conditions 

The  Kernel  primitive  K_special_func tion  shall  detect  and  return  the  following 
exception  (error)  conditions. 

EX:  insufficient  integrity  level  for  function  requested 
EX:  invalid  parameter  block 


3-2-31  Kernel  Function:  K  unlink 


3. 2.31.1  Inputs 

The  Kernel  primitive  K_unlink  shall  take  the  following  parameters. 
fSeid:  SEID  of  file  to  be  unlinked 


3.2.31.2  Processing 

K_unlink  shall  decrement  the  file  reference  count  of  the  specified  file. 
When  the  file  reference  count  has  decreased  to  zero,  the  file  shall  be  deleted 
after  any  processes  having  it  open  either  close  it  or  terminate.  If  the  refer¬ 
ence  count  is  zero  but  the  file  has  not  been  deleted  due  to  processes  having  it 
open,  it  cannot  be  opened.  The  security  and  integrity  checking  shall  be  as  if 
the  file  were  being  opened  for  reading  and  writing.  No  discretionary  access 
checking  shall  be  done  by  the  Kernel,  allowing  processes  privileged  to  use  this 
primitive  to  perform  whatever  checking  they  chose  to. 

The  use  of  K_unlink  may  be  optionally  restricted  to  processes  privileged  to 
issue  the  call.  This  option  should  be  exercised  when  the  UNIX  Emulator  (or 
similar  subsystems  including  higher  level  directories)  will  be  included  in  th 
system.  The  unhindered  use  of  K_unlink  can  harm  the  integrity  of  the  UNI 


Version  4.4 


-  53  - 


WDL-TR7932 


v  x 


Security  Kernel  B5  Specification 


directory  structure  created  by  the  Emulator.  In  cases  in  which  no  Emulator  will 
be  Included,  the  restriction  on  the  use  of  K_unlink  may  be  lifted. 

The  Directory  Manager  of  the  UNIX  Emulator  [Emulator  78]  should  perform 
additional  access  checks  in  the  emulation  of  the  UNIX  unlink(II)  call.  In  par¬ 
ticular,  the  user  should  have  write  access  to  the  directory  from  which  the  name 
is  being  deleted. 

3.2.31.3  Outputs 

The  Kernel  primitive  K_unlink  shall  return  the  following  information, 
ec:  error  conditions 

The  Kernel  primitive  K_unlink  shall  detect  and  return  the  following  exception 
(error)  conditions. 

EX:  insufficient  privilege  (optional,  see  above) 

EX:  object  does  not  exist  or  is  inaccessible  due  to  security  or  integrity 
considerations 

EX:  object  was  not  a  file  (devices  cannot  be  unlinked,  their  SEIDs  are  per¬ 
manently  assigned) 

EX:  object  resides  on  a  read-only  file  system 


3.2.32  Kernel  Function:  K  unmount 
3.2.32.1  Inputs 

The  Kernel  primitive  K_unmount  shall  take  the  following  parameters. 
devSeid:  device  SEID  of  file  system  to  be  dismounted 


3.2.32.2  Processing 

The  Kernel  primitive  K_unraount  shall  logically  unmount  the  file  system 
specified  by  the  device  SEID.  To  unmount  a  file  system  the  following  checks 
must  be  satisfied: 

a.  the  process  must  have  the  privilege  to  issue  the  call 

b.  the  user  must  own  the  device 

c.  the  device  must  have  file  system  mounted  on  it 

d.  the  user  must  have  write  permission  to  the  extent 

e.  the  extent  must  be  quiescent  (no  open  files) 
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3.2.32.3  Outputs 

The  Kernel  primitive  K_unmount  shall  return  the  following  information, 
ec :  error  conditions 

The  Kernel  primitive  K_unmount  shall  detect  and  return  the  following  exception 
(error)  conditions. 

EX:  insufficient  privilege 

EX:  device  not  mounted  or  is  Inaccessible  due  to  security  or  integrity  con- 
siderat ions 

EX:  process  owner  (user  10)  is  not  the  same  as  the  device  owner  (user  10) 

EX:  process  does  not  have  write  discretionary  premissions  to  the  device 
EX:  files  still  open  on  the  device 

3.2.33  Kernel  Function:  K  walk,  process  table 
3.2.33.1  Inputs 

The  Kernel  primitive  K_walk_process_table  shall  take  the  following  parame¬ 
ters. 

n:  global  process  table  entry  requested 


3.2.33.2  Processing 

The  K_walk_proCess_table  primitive  shall  be  a  means  for  privileged  software 
to  obtain  the  SEIDs  of  active  processes.  The  primitive  shall  return  the  SEID  of 
the  process  which  occupies  slot  n  of  the  global  process  table.  This  SEID  can 
then  be  used  in  K_get_level  or  K_get_process_status  calls.  The  call  shall  fail 
if  the  process  does  not  posess  the  privilege  to  issue  it,  or  if  n  is  not  a  valid 
index  number  for  the  process  table. 

3.2.33.3  Outputs 

The  Kernel  primitive  K_waik_process_tab le  shall  return  the  following  infor¬ 
mation  • 

ec:error  conditions 

rSeid:  SEID  of  the  n-th  entry  in  the  process  table 

The  Kernel  primitive  K_walk_process_table  shall  detect  and  return  the  following 
exception  (error)  conditions. 

EX:  not  privileged  to  issue  call 

EX:  n  is  not  a  valid  process  table  index 
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3.2.34  Kernel  Function:  K  write  block 

3.2.34.1  Inputs 


The  Kernel  primitive  K_wr ite_block  shall  take  the  following  parameters, 
od:  open  object  descriptor 

blockNo:  logical  block  number  of  the  file  at  which  to  start  writing 

duFlle-vl. domain:  domain  in  which  data  to  write  resides 

duFile -vl .vAddr :  address  at  which  data  starts 

duFlle-vl.ldSpace:  space  of  data  area 

duFlle.size:  length  (in  bytes)  of  data  to  write 

id:  asynchronous  call  identifier 


3.2.34.2  Processing 

K_wrlte_block  shall  move  the  data  in  the  area  described  by  the  parameter 
block  Into  the  specified  block(s)  of  the  file  designated  by  od.  Security  and 
discretionary  access  conditions  shall  be  checked  at  time  of  K_open  on  the  file. 
If  the  file  was  not  opened  for  writing  (or  for  reading  and  writing)  an  exception 
shall  be  returned.  Other  exceptions  shall  include  bad  parameter  values  and  phy¬ 
sical  I/O  errors. 

The  Kernel  shall  not  maintain  information  about  where  in  the  file  the  last 
I/O  was  directed.  Thus,  it  is  the  responsibility  of  software  using  the  Kernel 
to  keep  such  information. 

Limited  numbers  of  asynchronous  K_write_block  requests  may  be  made.  If  the 
the  asynchronous  call  identifier  field  is  non-null,  K_write_block  may  return 
before  completion  of  the  requested  operation.  At  the  completion  of  the 
requested  operation,  the  Kernel  shall  transmit  an  message  to  the  requesting  pro¬ 
cess  containing  (at  least):  the  asynchronous  call  identifier,  the  number  of 
bytes  written,  and  other  device  dependent  9tatus  information. 

3.2.34.3  Outputs 

The  Kernel  primitive  K_write_block  shall  return  the  following  information, 
ec:  error  conditions 

The  Kernel  primitive  K_write_block  shall  detect  and  return  the  following  excep¬ 
tion  (error)  conditions. 

EX:  parameter  block  invalid,  or  segment  designated  is  not  readable 

EX:  open  descriptor  invalid 

EX:  open  descriptor  not  opened  for  writing 

EX:  attempt  to  write  to  a  blocked  terminal 

EX:  size  of  block  does  not  match  device  block  size  or  is  outside  allowable 
limits  for  device 
EX:  block  number  out  of  range 

EX:  size  of  data  area  would  result  in  a  block  number  out  of  range. 
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3.2.35  Kernel  Resource  Manager 

\  _  KSOS  Security  Kernel  shall  include  a  system  resource  manager  that  is 
logically  separate  from  the  physical  scheduling  mechanisms  of  the  Kernel.  The 
Kernel  Resource  Manager  may  either  be  made  part  of  the  Kernel  or  may  exist  as  an 
external  process.  The  Kernel  Resource  Manager  shall  perform  higher  level 
management  or: 

a.  processor  or  CPU  resources 

b.  physical  memory 

c.  process  segment  swapping  space 

The  Kernel  Resource  Manager  shall  attempt  to  maximize  the  utilization  of  all 
system-wide  resources.  The  Resource  Manager  shall  attempt  to  guarantee  fair  and 
equitable  service  to  all  processes  running  in  the  KSOS  environment.  Denial  of 
service  conditions  shall  be  avoided  whenever  possible.  Deadlock  conditions 
shall  also  be  avoided. 

The  operation  of  the  Kernel  Resource  Manager  requires  a  tightly  coupled 
interface  with  the  rest  of  the  Kernel.  If  the  Kernel  Resource  Manager  is  imple¬ 
mented  as  an  external  process,  Care  shall  be  taken  to  make  the  interface  as 
efficient  and  secure  as  possible. 

3-2.36  Secure  Terminal  Interface 


To  assure  non-spoofable  communications  between  the  user  terminal  and  KSOS 
trusted  software,  the  Security  Kernel  shall  provide  a  secure  terminal  interface. 
This  function  shall  operate  as  follows.  One  of  the  characters  which  can  be 
typed  by  the  user  shall  be  reserved  for  the  Kernel  attention  character.  When 
the  user  transmits  this  character,  the  Kernel  shall  suspend  all  normal 
input/output  between  the  terminal  and  the  users'  processes.  The  Kernel  shall 
send  an  IPC  message  to  the  Secure  Initiator  [NKSR  78]  notifying  this  process 
that  a  user  at  the  specified  terminal  has  requested  a  special  secure  service. 
Further  communication  with  the  terminal  shall  only  be  permitted  to  processes 
permitted  to  open  the  terminal  using  a  SEID  specifying  secure  terminal  communi¬ 
cations.  Normal  communications  shall  resume  after  a  thaw  command  has  been 
issued  by  an  appropriately  privileged  process,  through  the 
K_secure_terminal_lock  primitive. 

3.2.37  Audit  Messages 

Standard  DoD  military  security  policy  requires  a  record  of  security  related 
operations  which  may  be  subject  to  audit.  The  KSOS  Kernel  shall  transmit  audit 
messages  to  the  secure  Audit  Capture  Process  [NKSR  78].  The  Security  Kernel 
shall  generate  audit  messages  for  (at  least)  the  following  security  related 
events . 

a.  file  creation 

b.  file  deletion 
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c.  any  operation  that  changes  the  file  owner,  security  level,  integrity  level, 
or  process  privileges  associated  with  process  image  files 

d.  available  resource  exhaustion  conditions  for  the  resources: 

1.  available  processes 

2.  file  space 

3.  IPC  message  buffer  space. 

e.  any  access  attempt  denied  because  of  security  or  integrity  violations 

Audit  messages  may  be  generated  for  other  security  related  events  to  be  deter¬ 
mined  by  the  development  contractor  Subject  to  Government  review  and  approval. 
Kernel-level  audit  functions  shall  be  Capable  of  being  selectively  disabled  dur¬ 
ing  system  generation  at  the  discretion  of  the  System  Security  Officer.  The 
exact  format  of  the  audit  messages  and  the  mechanism  by  which  they  are  transmit¬ 
ted  shall  be  left  to  the  development  contractor  subject  to  Government  approval. 

3.2.38  Kernel  Trap  Management 

3. 2. 38. 1  Inputs 

The  inputs  to  the  Security  Kernel  trap  management  function  shall  be  the 
various  processor  exception  conditions  and  device  interrupts.  On  the  PDP-11 /70, 
these  conditions  are  vectored  to  specific  memory  locations  which  shall  be  acces¬ 
sible  only  from  kernel  domain  software. 

3.2.38.2  Processing 

The  Security  Kernel  shall  dispatch  device  interrupts  to  the  appropriate 
peripheral  device  handler.  In  the  PDP-11 /70  implementation  of  KSOS,  device 
interrupt  handling  shall  be  limited  to  the  Security  Kernel.  In  other  computer 
architectures  which  can  guarantee  the  protection  and  security  of  user  level  dev¬ 
ice  handling.  These  functions  could  be  located  outside  the  perimeter  of  the 
Security  Kernel. 

Certain  processor  exception  conditions  shall  be  reflected  to  the  supervisor 
domain  of  a  user  process,  e-g.,  the  UNIX  Emulator.  The  processor  exception  con¬ 
ditions  reflected  outwards  shall  be  those  traps  caused  by  the  software  executing 
outside  the  domain  of  the  Kernel.  The  PDP-11 / 70  version  of  KSOS,  the  following 
traps  shall  be  reflected  to  supervisor  domain  software  by  means  of  the  pseudo¬ 
interrupt  mechanism: 

a.  Illegal  or  reserved  instruction  exceptions.  Illegal  instruction  codes. 
Reserved  instructions  executed  in  user  or  supervisor  domain. 

b.  Breakpoint  traps.  Execution  of  the  BPT  instruction.  Trace  traps. 

c.  IOT  instruction  traps.  (Causes  UNIX  abort.) 
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d.  TRAP  instruction-  (Causes  entry  to  UNIX  emulator  dispatch-) 

e-  Floating  point  errors-  Illegal  floating  point  operation  codes.  Floating  to 
integer  conversion  errors.  Floating  underflow  and  overflow.  Floating  unde¬ 
fined  variable.  Maintenance  trap. 

f.  Memory  management  traps-  Non-resident  segment  trap.  Segment  length  abort- 
Read  only  access  violation.  Memory  management  trap. 

Certain  trap  conditions  represent  either  system  hardware  failures,  or  serious 
problems  internal  to  the  Kernel.  These  trap  conditions  shall  cause  an  unplanned 
system  shutdown.  Where  possible,  the  system  should  cotanunicate  the  cause  of  the 
unplanned  shutdown  either  by  sending  information  to  the  Audit  Captuie  Process  or 
by  printing  a  message  on  the  system  console- 

3.2-39  Pseudo  Interrupts 

The  Kernel  shall  provide  a  pseudo  interrupt  facility  to  be  used  by  the  IPC 
mechanism  and  for  trap  reflection  and  timer  interrupts.  The  mechanism  for  the 
PDP-11/70  implementation  shall  set  the  program  counter  and  processor  status  word 
to  values  retrieved  from  fixed  locations  in  the  supervisor  domain.  The  proces¬ 
sor  status  word  shall  be  mashed  before  actually  being  used  to  prevent  the  user 
from  specifying  the  kernel  mode-  Processes  shall  be  able  to  inhibit  pseudo 
interrupts  through  the  appropriate  settings  of  parameters  in  the  type  dependent 
information  for  the  process.  The  K_interrupt_retum  call  shall  be  the  mechanism 
for  resuming  normal  processing  after  a  pseudo  interrupt.  The  call  shall  restore 
the  state  of  the  process  from  the  values  contained  in  the  pseudo  interrupt  vec¬ 
tor.  These  locations  may  be  modified  by  the  software  involved  in  interrupt  pro¬ 
cessing.  The  Kernel  shall  prevent  the  process  from  increasing  its  accessible 
domains  by  masking  the  processor  status  word  before  restoring  it. 

3.2.40  Special  Requirements 

Because  the  Security  Kernel  CPCI  is  the  heart  of  the  system's  security,  it 
shall  be  produced  with  extraordinary  precision  and  thoroughness.  The  System 
Specif ication  (Type  A)  [A-Specs  78]  describes  the  design  and  implementation 
standards  to  be  followed  in  the  Security  Kernel  CPCI.  The  Security  Kernel  shall 
be  designed  and  implemented  in  a  manner  which  is  amenable  to  eventual  formal 
proof  of  the  security  properties  of  the  system. 

The  Security  Kernel  shall  be  designed  to  facilitate  its  modification  and 
enhancement*  It  should  be  recognized  that  any  modifications  to  the  Security 
Kernel  may  invalidate  all  or  part  of  the  proofs  of  system  security.  Thus,  modif¬ 
ication  efforts  must  be  carefully  controlled.  No  field  maintenance  of  the  Secu¬ 
rity  Kernel  shall  be  permitted. 

3.2.40.1  Human  Performance 

This  paragraph  is  not  applicable  to  this  specification. 
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3.2.40.2  Government  Furnished  Property  List 

The  Security  Kernel  CFCI  shall  be  implemented  in  a  Government-approved 
language.  The  compiler  for  this  language  may  be  furnished  by  the  Government. 

3. 3  Adaptation 

The  Security  Kernel  shall  be  capable  of  adapting  to  any  of  the  hardware 
configurations  shown  in  the  System  Specification  [A-Specs  78].  The  creation  of 
a  Security  Kernel  for  a  particular  configuration  shall  be  an  automated  process 
designed  to  be  performed  by  personnel  without  extensive  computer  knowledge.  The 
mechanism  shall  employ  checksums  or  similar  techniques  to  assure  the  integrity 
of  the  Inputs  to  the  system  generation  process.  The  Security  Kernel  shall 
operate  correctly  in  a  configuration  that  is  reduced  from  the  one  for  which  it 
was  generated.  This  KSOS  System  Generation  mechanism  is  discussed  in  the  Non- 
Kernel  Security  Related  Software  CPCI  Specification  [NKSR  78]. 

3.3.1  General  Environment 

The  Kernel  and  the  Non-Kernel  Security  Related  Software  shall  establish 
and  enforce  a  maximum  security  level  for  the  system  as  a  whole  and  for  each 
peripheral  device  and  disk  extent.  In  specifying  the  maximum  level  for  peri¬ 
pheral  devices,  the  System  Security  Officer  should  consider  the  physical  loca¬ 
tion  of  the  device,  the  protection  of  any  connecting  communication  lines,  and 
the  personnel  which  would  have  access  to  the  device.  Individual  sites  may  be 
governed  by  specific  policies  in  this  area. 

3.3.2  System  Parameters 

The  size  of  all  system  tables  and  arrays  shall  be  parameterized  to  allow 
them  to  be  changed  easily.  All  manifest  constants  shall  also  be  parameterized. 

3.3.3  System  Capacities 

The  Security  Kernel  shall  be  capable  of  supporting  the  maximum  hardware 
configuration  defined  in  the  System  Specifications.  All  terminals  in  that  con¬ 
figuration  shall  be  capable  of  being  simultaneously  on-line.  The  Security  Ker¬ 
nel  shall  be  capable  of  supporting  at  least  fifty  (50)  active  processes. 
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4.  QUALITY  ASSURANCE  PROVISIONS 
4- 1  Introduction 


The  underlying  philosophy  of  the  overall  KSOS  quality  assurance  is  to  pro¬ 
vide  a  convincing  demonstration  of  the  security  and  completeness  of  the  system. 
Testing  and  quality  assurance  are  a  complement  to  the  formal  verification 
aspects  of  KSOS.  All  testing  on  KSOS  shall  be  conducted  at  the  development 
contractor's  facility. 

KSOS  shall  be  subject  to  the  technical  reviews  and  audit  procedures  of 
MIL-STD-1 52 1A,  Appendices  A-F .  The  following  technical  reviews  and  audits  will 
be  conducted: 

a.  System  Requirements  Review  (Appendix  A) 

b.  System  Design  Review  (Appendix  B) 

c.  Preliminary  Design  Review  (Appendix  C) 

d.  Critical  Design  Review  (Appendix  D) 

e.  Functional  Configuration  Audit  (Appendix  E) 

f.  Physical  Configuration  Audit  (Appendix  F) 

The  Critical  Design  Review  shall  include  a  review  of  any  mathematical 
proofs  showing  that  the  design  meets  the  requirements  of  the  Government  approved 
DoD  security  model- 

The  Functional  Configuration  Audit  shall  be  the  vehicle  for  the  formal 
review  of  the  design  versus  the  mathematical  description.  The  Physical  Confi¬ 
guration  Audit  shall  be  the  vehicle  for  the  formal  review  of  the  "as  built"  com¬ 
puter  programs  versus  both  their  design  and  their  supporting  documentation.  In 
addition,  the  Physical  Configuration  Audit  shall  verify  that  the  implementation 
requirements  of  the  Type  A  System  Specifications  have  been  met.  Both  audits 
shall  include  review  of  an:  relevant  mathematical  proofs  of  correctness. 

4.1.1  Category  I  Testing 

The  demonstration  that  the  requirements  of  Section  3  have  been  met  shall 
consist  of  a  combination  of  formal  inspection  of  the  CPCI  and  tests  which  demon¬ 
strate  that  the  CPCI  meets  its  functional  requirements.  The  tests  on  the  Secu¬ 
rity  Kernel  shall  exercise  each  of  the  options  for  each  primitive-  To  the 
extent  feasible,  the  tests  shall  attempt  to  exercise  combinations  of  parameters 
to  the  Kernel  Calls.  Test  sequences  shall  include  cases  which  are  expected  to 
fail,  for  example  tests  which  deliberately  attempt  to  violate  security.  All  the 
exception  conditions  defined  in  Section  3.  shall  be  so  tested. 

4.1.2  Category  II  Testing 

The  KSOS  system  shall  be  subject  to  an  overall  system  test  (Category  II)  In 
accordance  with  the  System  Specification  (Type  A)  and  the  development  contract. 
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This  Category  II  test  shall  demonstrate  that  the  three  CPCI's  which  make  up  the 
KSOS  system  function  correctly  together-  The  Category  II  testing  shall  attempt 
to  represent  a  typical  user  load  including  at  least  ten  (10)  on-line  terminals 
and  a  network  connection.  To  the  extent  feasible,  the  Category  II  testing  shall 
also  be  automated  through  the  use  of  shell  scripts,  and  (optionally)  another 
computer  system  emulating  the  terminal  load. 
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Table  I  -  Quality  Assurance 

Assurance  techniques: 

NA  Not  Applicable 

V  Verification 

F  Formal  Specification 

T  Testing 

D  Demonstration 

A  Analysis 

I  Inspection 

Applicable  test  types: 

1  Module  level  testing 

2  Integration  testing 

3  Acceptance  testing 


Requirement 

Assurance 

Techniques 

Test 

type 

NA  V 

F 

T 

D 

A 

I 

1 

2 

3 

3. 1.1.1. 

X 

X 

X 

X 

X 

X 

X 

3.  1.1.2. 1.1. 

X 

X 

X 

X 

X 

X 

X 

X 

3. 1.1. 2. 1.2. 

X 

X 

X 

X 

X 

X 

X 

X 

3.  1.1.2.  1.3. 

X 

X 

X 

X 

X 

X 

X 

X 

3.  1.1.2. 1.4. 

X 

X 

X 

X 

X 

X 

X 

X 

3. 1.1. 2. 1.5. 

X 

X 

X 

'I 

X 

X 

X 

X 

3.  1.1. 2. 2. 

X 

X 

X 

X 

X 

X 

X 

3.  1. 1-2.3. 

X 

3.  1. 1.2.4. 

X 

X 

X 

X 

X 

X 

X 

3. 1.1. 2. 5. 

X 

X 

X 

X 

X 

X 

X 

X 

3. 1.1. 2. 6. 

X 

X 

X 

X 

X 

X 

X 

3.2.1.  -  3.2.34 

* 

X 

X 

X 

X 

X 

X 

X 

X 

3.2.35. 

X 

X 

X 

X 

X 

X 

X 

X 

3.2.36. 

X 

X 

X 

X 

X 

X 

X 

3.2.37. 

X 

X 

X 

X 

X 

X 

X 

X 

3.  38. 

X 

X 

X 

X 

X 

X 

X 

X 

3.2.39. 

X 

X 

X 

X 

X 

X 

X 

X 

3.2.40. 1. 

X 

3.2.40.2. 

X 

3.  3. 

X 

X 

3.3. 1. 

X 

X 

3.3.2. 

X 

3.3.3. 

X 

X 

X 

X 

X 

*  Selected  modules  will  be  shall  be  formally  verified  on  a 
time  and  materials  basis. 
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5.  PREPARATION  FOR  DELIVERY 


This  section  is  not  applicable  to  this  specification. 
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6.  NOTES 

This  section  is  not  applicable  to  this  specification* 
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10.  APPENDIX 
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10.  APPENDIX 

This  appendix  presents  the  formal  specifications  for  the  KSOS  Security 
Kernel.  The  specifications  describe  the  interface  thac  the  Kernel  shall 
present  to  its  users  at  the  Kernel  call  level.  These  formal  specifications 
and  the  textual  descriptions  of  the  Kernel  call  interface  found  in  Section  3 
are  intended  to  be  be  used  side-by-side,  each  serving  to  illuminate  the  other. 
The  formal  specifications  are  written  in  the  SPECIAL  (SPECIf ication  and  Asser¬ 
tion  Language)  language  described  by  [Roubine  and  Robinson  77]. 

For  the  purposes  of  specification,  the  Kernel  has  been  decomposed  into 
several  modules  which  are  viewed  as  being  hierarchically  ordered.  A  convention 
has  been  followed  that  each  module  is  referred  to  by  a  three-letter  anenonic 
name  derived  from  its  function. 

Each  of  the  specification  modules  represents  an  incremental  aostract 
machine,  built  upon  the  abstract  machines  that  come  below  it  in  the  hierarchy. 
A  module  contains  descriptions  of  the  data  types  which  it  manipulates,  and 
functions  which  represent  the  state  variables  (V-functlons )  and  primitive 
operations  (O-functlons )  of  the  abstract  machine.  The  functions  of  a  module 
may  be  thought  of  as  being  the  mechanism  of  that  module's  abstract  machine. 

Not  all  the  functions  of  a  module  are  necessarily  "visible  to"  (i.e. 
available  for  use  by)  ocher  modules.  Furthermore,  it  is  a  strict  rule  of  the 
design  methodology  employed  that  no  function  at  a  given  level  in  the  hierarchy 
is  ever  visible  below  chat  level. 

The  modules  contain  varying  amounts  of  mechanism.  This  is  dictated  by  the 
extent  to  which  the  Kernel  calls  they  mechanize  alter  the  state  of  the  Kernel. 
A  ground  rule  followed  in  writing  these  specifications  has  been  to  specify 
noching  which  is  not  somehow  visible  at  the  Kernel  call  interface. 

All  the  Kernel  calls,  data  types,  and  data  structures  which  are  visible 
at  the  Kernel  call  interface  have  been  collected,  for  ease  of  reference  into 
che  topmost  layer  of  the  hierarchy  ("KOI").  The  effects  of  any  Kernel  call  nay 
be  cetermined  from  che  specifications  by  finding  the  entry  for  chat  tall  in 
KZR,  and  then  following  che  flow  of  implication  through  the  hierarchy. 

Anocner  useful  way  in  which  the  specifications  may  be  studied  is  to 
determine  the  mechanisms  and  structures  supporting  a  particular  Kernel 
feature.  This  is  best  done  by  examination  of  the  module(s)  which  specify  Che 
feature. 

SRI  International  has  developed  and  maintains  cools  which  can  verify  che 
internal  consistency  of  a  sec  of  formal  specifications  written  in  SPECIAL. 
These  specifications  have  been  processed  through  these  cools  and  have  been 
judged  by  the  tools  to  be  syntactically  correct  and  semantically  consistent. 
In  the  future  these  specifications  will  be  processed  by  other  tools  to  verify 
thac  they  do  indsed  provide  a  system  consistent  with  che  mathematical  security 
model  * 
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Wed  Mar  18  11:11:49  1981 


1  $("  MODULE:  ker. specs  (version  4.8) 

2  CONTENTS:  Kernel  Calls 

3  TYPE:  SPECIAL. specifications 

4  LAST  CHANGED:  12/23/80,  16:51:22 

5  •') 

6 

7 

8  MODULE  ker 

9 

10 

11  TYPES 

12 

13  $(f rom  mac ) 

14  vAddrType:  {0  ..  MACmaxVAddr } ; 

15 

16  $(from  smx) 

17  nonDisType:  STRUCT_OF( 

18  INTEGER  securityLevel ;  SET_0F  securityCat  securltyCatS ; 

19  INTEGER  IntegrityLevel ;  SET_0F  IntegrltyCat  IntegrityCatS) ; 

20  daType:  SETjOF  daMode; 

21  modeStruct:  STRUCT_OF(daType  ownerMode,  groupMode,  allMode); 

22  tliStruct :  STRUCT_0F ( no nDis Type  nd; 

23  modeStruct  ms;  INTEGER  owner,  group;  SET_0F  privType  prlv); 

24 

25  $(FR0M  pvm) 

26  virtualLocation: 

27  STRUCT_OF(domainType  domain;  spaceType  idSpace;  vAddrType  vAddr); 

28  globalData : 

29  STRUCT_OF( BOOLEAN  sharable,  swappable,  sticky,  memAdvlse,  executable); 

30  statusStruct: 

31  STRUCT_0F(globalData  gl ;  direction  growth;  INTEGER  size;  seld  iseid; 

32  segDes  udes ;  virtualLocation  vloc;  daType  da;  BOOLEAN  mapped); 

33  pBlock:  STRUCT_0F( virtual Location  vloc;  INTEGER  size); 

34 

35  $(FR0M  fca) 

36  fileStatus:  STRUCT_0F ( INTEGER  nBlocks ,  linkCount,  time Last Mod;  seld  subtype; 

37  BOOLEAN  openAtCrash); 

38  asyncld:  CHAR; 

39  ioStatus:  STRUCT_OF( INTEGER  devlndep,  devDep); 

40  fileNsp:  {129  ..  255};  $(nsp  values  for  file  systems) 

41 

42  $(from  pro) 

43  piLevelType:  {PROminPiLevel  ..  PROmaxPiLevel} ;  $(pseudo  interrupt  level  range) 

44  piEntryType:  STRUCT_0F(piLevelType  oldPil; 

45  piLevelType  oldPil; 

46  INTEGER  oldPc; 

47  INTEGER  oldPs ; 

48  INTEGER  parameter; 

49  INTEGER  newPc; 

50  INTEGER  newPs ) ; 

51  piVectorType:  {VECT0R_0F  piEntryType  piv  |  LENGTH(piv)  *  PROmaxPiLevel  * PROminPiLevel } ; 

52  ipcqType :  {VECT0R_0F  ipcMessageType  zz  |  LENGTH (zz )  <■  IPCmaxMessageCount } ; 

53  ipcTextType:  {VECT0R_0F  CHAR  vc  |  LENGTH(vc)  ■  IPCmaxMessageLength } ; 

54  IpcMessageType:  STRUCT_0F(seid  sender;  ipcTextType  text); 

55  processStatusType:  STRUCT_0F(aeid  self; 

56  seid  parent; 
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57 

INTEGER  family; 

58 

INTEGER  realUser; 

59 

INTEGER  rea lGroup ; 

60 

INTEGER  pc;  $ (program  counter) 

61 

INTEGER  ps ;  $(processor  status) 

62 

piLevelType  pil; 

63 

piVectorType  piv; 

64 

ipcqType  ipcq; 

65 

INTEGER  advPrio;  $(advisory  priority) 

66 

INTEGER  timer Alarm;  $ (one 'zero  crossing  *>  pi) 

67 

INTEGER  supervis orTiming; 

68 

INTEGER  userTiming; 

69 

BOOLEAN  timTog);  $(timer  toggle  TRUE  is  ON) 

70 

71 

72 

EXTERN ALREFS 

73 

74 

FROM  mac : 

75 

76 

77 

INTEGER  MACmaxVAddr ; 

FROM  smx: 

78 

seid:  DESIGNATOR; 

79 

privType : 

{ 

80 

privFileUpdateStatus , 

privLink, 

81 

privLockSeg, 

privModifyPriv, 

82 

privMount , 

privSetLevel, 

83 

privStickySeg, 

privSetPath, 

84 

privViolSimpSecurity, 

privViolStarSecurity, 

85 

prlvViolSimpIntegri ty. 

privViolStarlntev  rity. 

86 

privViolDiscrAccess , 

privRealizeExecPermission 

87 

privSignal, 

pri vWalkPTable , 

88 

privHalt, 

privKemelCall, 

89 

privViolCompartments , 

privSetComm, 

90 
0  1 

privlmmigrate 

i . 

j  1 

92 

J  » 

93 

daMode:  {daRead, 

daWrite,  daExecute}; 

94  securityCat:  DESIGNATOR; 

95  integrityCat:  DESIGNATOR; 

96  domainType:  {nullDomain,  kernelDomain,  supervisorDomain ,  userDomain} ; 

97 

98  FROM  pvm : 

99  segDes:  DESIGNATOR; 

100  spaceType:  {nullSpace , iSpace ,  dSpace}; 

101  direction:  {up,  down}; 

102  OVFUN  PVMbuild (seid  pSeid;  statusStruct  ss ;  modeStruct  ms) 

103  *>  STRUCT_OF(seid  segSeid;  segDes  segd)  result; 

104  OFUN  PVMdestroy(seid  pSeid;  segDes  segd); 

105  VFUN  PVMgetSegmentStatus (seid  pSeid,  segSeid;  segDes  segd)  J>  statusStruct  st; 

106  OFUN  PVMsetSegmentStatus (seid  pSeid,  segSeid;  globalData  gl); 

107  OFUN  PVMreraap(seid  pSeid;  segDes  in;  virtualLocation  vl;  daType  d; 

108  BOOLEAN  vlFlg,  daFlg;  segDes  out;  INTEGER  outSize; 

109  BOOLEAN  osFlg); 

110  OVFUN  PVMrendezvous (seid  pSeid,  segSeid;  virtualLocation  vl;  daType  d) 

111  J>  segDes  segd; 

112 
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113  FROM  fca: 

114  openDescrlptor :  DESIGNATOR; 

115  openModes:  {omRead,  omWrite,  omExcluslveRead,  omExclusiveWrite} ; 

116  lOfunction:  {rewind,  etc); 

117  OFUN  FCAclose (seid  pSeld;  openDescrlptor  od); 

118  OVFUN  FCAcreate(se id  pSeid,  nspSeid;  SET_OF  openModes  mode;  modeStruct  d; 

119  openDescrlptor  stCap) 

120  J>  STRUCT_OF(seid  fSeid;  openDescrlptor  od)  result; 

121  OVFUN  FCAopen(seld  pSeid,  oSeid;  SET_0F  openModes  om;  openDescrlptor  stCap) 

122  J>  openDescrlptor  od; 

123  VFUN  FCAgetF lie Status (seid  pSeid,  fSeid)  *>  fileStatus  fst; 

124  OFUN  FCAsetFileStatus (seid  pSeid,  fSeid;  ileStatus  newfst); 

125 

126  FROM  fmi : 

127  OFUN  FCAlink(seid  pSeid,  fSeid); 

128  OVFUN  FCAnount (seid  pSeid,  dev,  root;  BOOLEAN  readonly)  f>  fileNsp  newNsp; 

129  OFUN  FCAterminalLock(seid  pSeid,  devSeid); 

130  OFUN  FCAunl ink (seid  pSeid,  fSeid); 

131  OFUN  FCAunmount (seid  pSeid;  fileNsp  fsNsp); 

132 

133 

134  FROM  pro: 

135  INTEGER  IPCmaxMessageCount ; 

136  INTEGER  IPCmaxMess age Length; 

137  INTEGER  PROminPiLevel ; 

138  INTEGER  PROmaxPiLe vel ; 

139  OVFUN  PROf otk(seid  pSeid)  *>  seid  childSeid; 

140  VFUN  PROgetProcessStatus (seid  pSeid,  getSeid)  J>  process StatusType  ps ; 

141  OFUN  PROinterruptReturn(seid  pSeid); 

142  OFUN  PR0invoke(seid  pSeid,  imraSeid;  segDes  arg); 

143  OFUN  PROnap(seid  pSeid;  INTEGER  timeOut); 

144  OFUN  PROpost(seid  pSeid,  receiver;  BOOLEAN  pseudolnt;  IpcTextType  msg); 

145  OVFUN  PROrecei ve(seid  pSeid;  INTEGER  timeOut)  J>  ipcMessageType  msg; 

146  OFUN  PROreleaseProcess (seid  pSeid,  rSeid); 

147  OFUN  PROsetProcessStatus (seid  pSeid,  procSeid;  pro cess Status Type  ps ) ; 

148  OFUN  PROsignal (seid  sender,  receiver;  IpcTextType  signalMsg); 

149  OVFUN  PROspawn(seid  pSeid,  immSeid;  segDes  arg)  *>  seid  childSeid; 

150  VFUN  PROwalkProcess Table (seid  pSeid;  INTEGER  n)  J>  seid  rSeid; 

151 

152  FROM  lev: 

153  VFUN  LEVgetObjectLevel (seid  pSeid,  objSeid)  *>  tiiStruct  level; 

154  OFUN  LEVsetOb jectLevel(seid  pSeid,  objSeid;  tiiStruct  level); 

155 

156  FROM  spf : 

157  SPFfunctionType :  {syncSPF,  immSegSPF,  sysHaltSPF,  levelSetSPF} ; 

158 

159  FROM  pbl: 

160  OFUN  PBLdeviceFunction(seid  pSeid;  openDescrlptor  od;  lOfunction  f; 

161  pBlock  arguments,  status;  asyncld  id); 

162  OVFUN  PBLreadBlock(seid  pSeid;  openDescrlptor  od;  INTEGER  blockNo; 

163  pBlock  duFile;  asyncld  as) 

164  *>  STRUCT_0F( INTEGER  bytesRead;  ioStatus  errst)  result; 

165  OFUN  PBLspecialFunction(seid  pSeid;  SPFfunctionType  fn;  pBlock  parra); 

166  OVFUN  PBLwriteBlock(seid  pSeid;  openDescriptor  od;  INTEGER  blockNo; 

167  pBlock  duFile;  asyncld  as) 

168  *>  ioStatus  ios ; 


Version  4.4 


-70- 


WDL-TR7932 


ker. specs  Page  4 


Wed  Mar  IS  11:11:49  1981 


169 

170 

171  FUNCTIONS 

172 

173  $("Note  regarding  implementation:  The  implicit  parameter  pSeid  is 

174  implemented  by  passing  a  null  seld  to  the  kernel  interface.  The  rail 

175  seid  is  converted  upon  entering  the  interface  to  the  seid  of  the 

176  calling  process.  As  a  consequence,  for  a  process  to  lean  its  own 

177  seid,  it  suffices  to  call  K_get_Process  Status  with  a  null  seid.") 

178 

179  $(Visible  Kernel  Functions  in  Alphabetical  Order) 

180 

181  OVFUN  K_build_segment (status Struct  ss ;  modeStruct  ms) 

182  (seid  pSeid]  J>  STRUCT_0F(seid  segSeld;  segDes  segd)  result; 

183  $(K_build_segment ) 

184  EXCEPTIONS 

185  EXCEPTI0NS_0F  PVMbuild(pSeid ,  ss,  ms); 

186  EFFECTS 

187  result  -  EFFECTS_0F  PVMbuild(pSeid,  ss,  ms); 

188 

189  OFUN  Kclose (openDescriptor  od)[seid  pSeid];  $(K_close) 

190  EXCEPTIONS 

191  EXCEPTIONS_OF  FCAclose (pSeid,  od); 

192  EFFECTS 

193  EFFECTS_OF  FCAclose(pSeid,  od); 

194 

195  OVFUN  K_create(seid  nspSeid;  SET_0F  openModes  mode;  modeStruct  d; 

196  openDescriptor  stCap)[seid  pSeid] 

197  *>  STRUCT_OF(seid  fSeid;  openDescriptor  od)  return;  $(K_create) 

198  EXCEPTIONS 

199  EXCEPTI0NS_0F  FCAcreate(pSeid,  nspSeid,  mode,d,  stCap); 

200  EFFECTS 

201  return  =  EFFECTS_0F  FCAcreate(pSeid,  nspSeid,  mode,d,  stCap); 

202 

203  OFUN  K_device_function(openDescriptor  od;  IOfunction  f; 

204  pBlock  arguments,  status;  asyncld  id) 

205  [seid  pSeid];  $(K_device_function) 

206  EXCEPTIONS 

207  EXCEPTI0NS_0F  PBLdeviceFunction(pSeid ,  od,  f,  arguments,  status,  id); 

208  EFFECTS 

209  EFFECTS_0F  PBLdeviceFunction(pSeid,  od,  f,  arguments,  status,  id); 

210 

211  OVFUN  K_fork( ) (seid  pSeid]  J>  seid  childSeid;  $(K_fork) 

212  EXCEPTIONS 

213  EXCEPTI0NS_0F  PROfork(pSeid) ; 

214  EFFECTS 

215  childSeid  -  EFFECTS_0F  PROf ork(pSeid) ; 

216  $("ChildSeid  is  returned  to  the  (original)  process;  pSeid  (parent  seid) 

217  is  returned  to  the  newly  created  child") 

218 

219  VFUN  K_get_file_status (seid  fSeid) [seid  pSeid]  *>  fileStatus  fst; 

220  $(K_get_file_status ) 

221  EXCEPTIONS 

222  EXCEPTIONSJOF  FCAgetFileStatus (pSeid,  fSeid); 

223  DERIVATION 

224  FCAgetFileStatus (pSeid,  fSeid); 
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225 

226  VFUN  K_get_ob ject_le vel (seld  ob jSeld) [seld  pSeld]  J>  tliStruct  otli; 

227  $(K_get_object_level) 

228  EXCEPTIONS 

229  EXCEPTlONSjOF  LEVgetObjectLeveKpSeld,  objSeld); 

230  DERIVATION 

231  LEVgetObjectLeve l(pSeld ,  objSeld); 

232 

233  VFUN  K_get  process_status (seid  getSeid )  [seld  pSeid]  J>  process  Status  Type  ps ; 

234  $(K_get_process_status ) 

235  EXCEPTIONS 

236  EXCEPTlONSjOF  PROgetProcessStatus (pSeid ,  getSeid); 

237  DERIVATION 

238  PROget Process  Status (pSeid ,  getSeid); 

239 

240  VFUN  K_get_segment_stat us (seid  segSeid;  segDes  segd)[seid  pSeid]  *> 

241  statusStruct  st; 

242  $(K_get  segmentstatus ) 

243  EXCEPTIONS 

244  EXCEPTIONSOF  PVMgetSegmentStatus(pSeid,  segSeid, segd) ; 

245  DERIVATION 

246  PVMgetSegraentStatus (pSeid,  segSeid, segd ) ; 

24  7 

248  OFUN  Kinterrupt_retum()  [seid  pSeid];  $(K_lnterrupt_return) 

249  EXCEPTIONS 

250  EXCEPTlONSjOF  PR0interruptReturn(pSeid ) ; 

251  EFFECTS 

252  EFFECTS_OF  PROinterruptRetum(pSeid); 

253 

254  OFUN  Kinvoke(seid  immSeid;  segDes  arg)[seid  pSeid];  $(K_invoke) 

255  EXCEPTIONS 

256  EXCEPTIONS_OF  PROinvoke(pSeid,  immSeid,  arg); 

257  EFFECTS 

258  EFFECTS_OF  PROinvoke(pSeid,  immSeid,  arg); 

259 

260  OFUN  K_link(seld  fSeid)[seid  pSeid];  $(K_link) 

261  EXCEPTIONS 

262  EXCEPTIONS_OF  FCAIink(pSeid ,  fSeid); 

263  EFFECTS 

264  EFFECTS_OF  FCAlink(pSeid ,  fSeid); 

265 

266  OVFUN  K_mount (seid  dev;  BOOLEAN  readonly ) [seid  pSeid]  $(K_mount) 

267  *>  fileNsp  newNsp; 

268  EXCEPTIONS 

269  EXCEPTIONS_OF  FCAmount (pSeid,  dev,  readonly); 

270  EFFECTS 

271  newNsp  *  EFFECTSjOF  FCAmount (pSeid,  dev,  readonly); 

272 

273  OFUN  K_nap ( INTEGER  timeOut ) [seid  pSeid];  $(K_nap) 

274  EXCEPTIONS 

275  EXCEPTIONS_OF  PROnap(pSeid,  timeOut); 

276  EFFECTS 

277  EFFECTS_OF  PROnap(pSeid,  timeOut); 

278 

279  OVFUN  K_open (seid  oSeid;  SET_OF  openModes  om;  openDescriptor  stCap) 

280  (seid  pSeid]  *>  openDescriptor  od;  $(K_open) 
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281  EXCEPTIONS 

282  EXCEPTIONS_OF  FCAopen(pSeid,  oSeld,  om,  stCap); 

283  EFFECTS 

284  od  ■  EFFECTS_OF  FCAopen(pSeid,  oSeld,  om,  stCap); 

285 

286  OFUN  K_post(seid  receiver;  BOOLEAN  pseudolnt ;  ipcTextType  msg)[seid  pSeid]; 

287  $(K_post) 

288  EXCEPTIONS 

289  EXCEPTIONS_OF  PROpost(pSeid,  receiver,  pseudolnt,  msg); 

290  EFFECTS 

291  EFFECTS_0F  PROpost (pSeid ,  receiver,  pseudolnt,  msg); 

292 

293  OVFUN  K_read_block(openDes criptor  od;  INTEGER  blockNo;  pBlock  duFile; 

294  asyncld  as)[seid  pSeid) 

295  J>  STRUCT_OF( INTEGER  bytesRead;  ioStatus  errst)  result;  $ (K__read_block) 

296  EXCEPTIONS 

297  EXCEPTI0NS__0F  PBLreadBlock(pSeid,  od,  blockNo,  duFile,  as); 

298  EFFECTS 

299  result  =  EFFECTS_0F  PBLreadBlock(pSeid,  od,  blockNo,  duFile,  as); 

300 

301  OVFUN  K_receive ( INTEGER  timeOut ) [s eid  pSeid]  *>  ipcMessageType  msg; 

302  $(K_receive) 

303  EXCEPTIONS 

304  EXCEPTI0NSJ3F  PROreceive (pSeid,  timeOut); 

305  EFFECTS 

306  msg  “  EFFECTS_0F  PRO receive (pSeid,  timeOut); 

307 

308  OFUN  K  releaseprocess (seid  rSeid)[seid  pSeid);  $(K_release_process) 

309  EXCEPTIONS 

310  EXCEPTIONS_OF  PROreleaseProcess (pSeid,  rSeid); 

311  EFFECTS 

312  EFFECTS_0F  PROreleaseProcess (pSeid,  rSeid); 

313 

314  OFUN  K_release_segment(segDes  segd)[seid  pSeid);  $(K_release_segment) 

315  EXCEPTIONS 

316  EXCEPTIONS_OF  PVMdes troy (pSeid,  segd); 

317  EFFECTS 

318  EFFECTS_0F  PVMdestroy(pSeid,  segd); 

319 

320  OFUN  K_remap(segDes  in;  virtualLocation  vl;  daType  d;  BOOLEAN  vlFlg,  daFlg; 

321  segDes  out;  INTEGER  outSize;  BOOLEAN  osFlg)[seid  pSeid); 

322  $(K_remap) 

323  EXCEPTIONS 

324  EXCEPTIONS_0F 

325  PVMremap(pSeid,  in,  vl,  d,  vlFlg,  daFlg,  out,  outSize,  osFlg); 

326  EFFECTS 

327  EFFECTS_OF 

328  PVMremap (pSeid,  in,  vl,  d,  vlFlg,  daFlg,  out,  outSize,  osFlg); 

329 

330  OVFUN  K_rendezvous_segment(seid  segSeid;  virtualLocation  vl;  daType  d) 

331  [seid  pSeid] 

332  *>  segDes  segd;  $(K_rendezvous_segraent ) 

333  EXCEPTIONS 

334  EXCEPTI0NS_0F  PVMrendezvous (pSeid,  segSeid,  vl,  d); 

335  EFFECTS 

336  segd  *  EFFECTS_OF  PVMrendezvous (pSeid,  segSeid,  vl,  d); 
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337 

338  OFUN  K.  secure_  terminal_lock(seid  devSeid  )  [seid  pSeid]; 

339  $(Kjsecure_tenninal_lock) 

340  EXCEPTIONS 

341  EXCEPTIONS_OF  FCAterminalLock(pSeid,  devSeid); 

342  EFFECTS 

343  EFFECTSOK  FCAtecminalLock(pSeid,  devSeid); 

344 

345  OFUN  K  set_f ile_status (seid  fSeid;  fileStatas  fst)[seid  pSeid]  ; 

346  ~  $(K_set_file_status ) 

347  EXCEPTION'S 

348  EXCEPTIONSjDF  FCAsetFileStatus (pSeid,  fSeid,  fst); 

349  EFFECTS 

350  EFFECTS_OF  FCAsetFileStatus (pSeid,  fSeid,  fst); 

351 

352  OFUN  K  set  object_level(seid  objSeid;  tiiStruct  level)[seid  pSeid]; 

353  $(K_set  object_level) 

354  EXCEPTIONS 

355  EXCEPTIONSJDF  L£VsetObjectLevel(pSeid,  objSeid,  level); 

356  EFFECTS 

357  EFFECTS _OF  LEVsetObjectLevel(pSeid,  objSeid,  level); 

358 

359  OFUN  K  set  _process_status (seid  procSeid;  processStatusType  ps)[seid  pSeid]; 

360  $(K_set_process_status ) 

361  EXCEPTIONS 

362  EXCEPTIONS  JDF  PROsetProcessStatus (pSeid,  procSeid,  ps); 

363  EFFECTS 

364  EFFECTSOF  PROsetProcessStatus (pSeid,  procSeid,  ps ) ; 

365 

366  OFUN  Kset jsegment_status (seid  segSeid;  globalData  gl)[seid  pSeid]; 

367  $(K_set_segment_status ) 

368  EXCEPTIONS 

369  EXCEPT IONS_OF  PVMsetSegraeatStatus (pSeid ,  segSeid,  gl); 

370  EFFECTS 

371  EFFECTS_OF  PVMsetSegmentStatus (pSeid,  segSeid,  gl); 

372 

373  OFUN  K._signal (seid  procSeid;  ipcTextType  sigMsg)[seid  pSeid];  $(K_signal) 

374  EXCEPTIONS 

375  EXCEPTIONS_OF  PROsignal(pSeid,  procSeid,  sigMsg); 

376  EFFECTS 

377  EFFECTS_OF  PROsignal(pSeid,  procSeid,  sigMsg); 

378 

379  OVFUN  K_spavn(seid  inmSeid;  segDes  arg)[seid  pSeid]  J>  seid  childSeid; 

380  _  $(K_spawn) 

381  EXCEPTIONS 

382  EXCEPTI0NS_0F  PROs pawn(pSeid,  immSeid,  arg); 

383  EFFECTS 

384  childSeid  -  EFFECTS_OF  PROs pawn( pSeid ,  imraSeid,  arg); 

385 

386  OFUN  K_special_function(SPFfunctionType  fn;  pBlock  parm)[seid  pSeid]; 

387  $(K_special_function) 

388  EXCEPTIONS 

389  EXCEPTIONSjDF  PBLspecialFunction(pSeid,  fn,  parm); 

390  EFFECTS 

391  EFFECTS_OF  PBLspecialFunction(pSeid,  fn,  parm); 

392 
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393  OFUN  K_unlink(seid  fSeid)[seid  pSeid];  $(K_unlink) 

394  EXCEPTIONS 

395  EXCEPTION S_OF  FCAunllnk(pSeid,  fSeid); 

396  EFFECTS 

397  EFFECTSjDF  FCAunlltik(pSeid,  fSeid); 

398 

399  OFUN  K_unmount (f ileNsp  fsNsp)[seid  pSeid];  $(K  unmount) 

400  EXCEPTIONS  ~ 

401  EXCEPTIONS_OF  FCAunmount (pSeid ,  fsNsp); 

402  EFFECTS 

403  EFFECTS_OF  FCAunmount(pSeid,  fsNsp); 

404 

405  VFUN  K_walk_process  _table( INTEGER  n)[seid  pSeid]  J>  seid  rSeid; 

406  $(K_walk_process_tabIe ) 

407  EXCEPTIONS 

408  EXCEPTIONS_OF  PROwalkProcessTableCpSeid, n) ; 

409  DERIVATION 

410  PROwalkProcess Table (pSeid, n) ; 

411 

412  OVFUN  K_wri te_block(openDes crip tor  od;  INTEGER  blockNo;  pBIock  duFile; 

413  asyncld  id)[seid  pSeid] 

414  *>  ioStatus  ios;  $(K_write_block) 

415  EXCEPTIONS 

416  EXCEPTIONS_OF  PBLwriteBlock(pSeid,  od,  blockNo,  duFile,  id); 

417  EFFECTS 

418  ios  -  EFFECTS_OF  PBLwriteBlock(pSeid,  od,  blockNo,  duFile,  id); 

419 

420 

421  END  MODULE 
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1  $("  MODULE:  ddf. specs  (version  2.5) 

2  CONTENTS:  Device  Dependent  Fur  .tions 

3  TYPE:  SPECIAL. specif ications 

4  LAST  CHANGED:  7/28/80,  09:22:51 

5  ") 

6 

7 

8  MODULE  ddf 

9 

10  TYPES 

11  deviceType:  {RK05,  RWP04 ,  RWP05 ,  RWP06 ,  RSW04 ,  TWE16,  TM11,  TU56,  PR11, 

12  PC11,  LP1 1 ,  IMPI1B,  LHDH} ; 

13  deviceStruct :  STRUCT_OF (BOOLEAN  addressable; 

14  INTEGER  minRequest,  maxRequest,  modSize,  maxBlock.No); 

15  $(properties  necessary  for  processing  10  requests  for  devices) 

16 

17  FUNCTIONS 

18 

19  VFUN  DDFdevlceData(de viceType  d)  *>  deviceStruct  ds ;  S(DDFdeviceData) 

20  $(for  a  given  type  of  device,  defines  the  10  behavior) 

21  INITIALLY 

22  ds  -  (IF  d  -  RK05 

23  THEN  STRUCT (TRUE ,  512,  65534,  512,  203*24*1) 

24  ELSE  IF  d  INSET  {RWP04 ,  RWP05 } 

25  THEN  STRUCT(TRUE,  512,  65534,  512,  22*19*411*1) 

26  ELSE  IF  d  -  RWP06 

27  THEN  STRUCT (TRUE ,  512,  65534,  512,  22*19*411*2*1) 

28  ELSE  IF  d  «  RSW04  THEN  STRUCT (TRUE,  512,  65534,  512,  2048*1) 

29  ELSE  IF  d  INSET  { TWE 1 6 ,  TM11}  THEN  STRUCT (FALSE,  12,  8191,  1,  0) 

30  ELSE  IF  d  -  TU56  THEN  STRUCT (TRUE ,  512,  512,  512,  578*1) 

31  ELSE  IF  d  INSET  {PR11,  PCI 1 }  THEN  STRUCT (FALSE ,  1,  1,  1,  0) 

32  ELSE  IF  d  ■  LPll  THEN  STRUCT (FALSE ,  1,  132,  1,  0) 

33  ELSE  IF  d  INSET  {IMP11B,  LHDH}  THEN  STRUCT ( FALSE ,  1,  8191,  1,  0) 

34  ELSE  ?); 

35 

36  END  MODULE 
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1  $("  MODULE:  fca. specs  (version  4.16) 

2  CONTENTS:  File  Capabilities 

3  TYPE:  SPECIAL. specifications 

4  LAST  CHANGED:  12/23/80,  16:34:45 

5  ") 

6 

7 

8  MODULE  fca 

9 

10 

11  $("This  module  manages  all  openable  objects,  i.e.,  those  that  are  referenced 

12  through  the  open  table  corresponding  to  a  process.  These  objects  include 

13  files,  devices  *  both  addressable  and  nonaddress  able* ,  terminals,  extents, 

14  and  subtypes. 

15 

16  Each  object  is  identified  by  a  seid.  Seids  for  devices,  terminals,  and 

17  subtypes  are  allocated  at  system  generation  time.  These  objects  are 

18  permanent,  and  cannot  be  dynamically  allocated  and  deallocated. 

19  Seids  for  files  are  allocated  by  this  module.  Seids  for  extents  are 

20  allocated  when  the  device  is  physically  mounted.  Physicial  mounting 

21  is  not  handled  at  this  time  "  logical  mounting  is  11  but  should  be. 

22 

23  Each  process  at  creation  is  assigned  an  open  table,  in  which  all  the 

24  open  objects  of  that  process  are  recorded,  along  with  their  mode  of 

25  access.  The  state  of  the  open  table  for  a  process  is  recorded  in  the 

26  values  of  the  V*functions  'FCAopenTableExis ts (pSeid) ' ,  which  tells 

27  whether  the  open  table  for  the  process  named  by  'pSeid'  exists,  and 

28  'FCAopenEntry(pSeid,  od ) ' ,  which  gives  the  seid  and  open  mode  for  the 

29  open  object  of  process  'pSeid'  named  by  the  open  Descriptor  "a 

30  designator  11  'od. ' 

31 

32  The  existence  of  an  openable  object  is  detected  by  a  defined  value  for 

J3  'FCAf ileStatus Info(f Seid) , '  where  'fSeid'  is  the  object's  seid.  Each 

74  object's  type  is  ascertained  by  looking  at  the  nsp  part  of  the  seid. 

35  Depending  on  the  type  of  the  object,  certain  V*functions  hold  additional 

36  information.  A  description  of  this  information  can  be  found  in  the 

37  comment  directed  at  each  type  of  object.") 

38 

39  $("  DEVICES  "  there  are  two  kinds  of  devices,  addressable  and  nonaddress  able ; 

40  an  addressable  device,  such  as  a  disk,  has  two  properties:  it  can  be 

41  accessed  via  a  block  number  or  address;  and  what  is  put  onto  the  device 

42  via  a  read  operation  is  retrieved  by  a  write  when  the  device  is  read  at 

43  the  same  address.  A  non* addressable  device,  such  as  a  tape  unit,  can  be 

44  viewed  as  having  an  infinite  stream  of  input  data  and  producing  an 

45  infinite  stream  of  output  data.  Each  kind  of  device  has  four  quantities 

46  associated  with  it:  a  minimum  request,  a  maximum  request,  a  size 

47  modulus,  and  a  maximum  block  number. 

48 

49  For  non’addressable  devices,  the 

50  size  modulus  must  be  1  and  the  maximum  block  number  is  meaningless. 

51  An  10  request  specifies  a  certain  number  of  characters  at  a  certain 

52  block  number.  The  number  of  characters  must  be  within  the  range 

53  defined  by  the  minimum  and  maximum  request  quantities  for  the  device, 

54  and  must  be  a  multiple  of  the  size  modulus.  The  block  number  must  be  with 

55  within  the  range  {0  ..  maximum  block  number}  for  the  device. 

56  ") 
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$("  TERMINALS  **  With  one  exception,  terminals  are  nonaddressable  devices 
whose  10  requests  are  United  to  small  multiples  of  a  single  character 
(~  255).  Terminals  however,  have  a  special  property.  To  enable  the 
user  to  change  the  security  level  of  his  job  without  changing  terminals, 
there  is  an  illusion  that  a  single  terminal  is  represented  by  a 
multiplicity  of  device  seids,  one  for  each  possible  login  security  level. 
Each  seid  represents  a  particular  secure  path  to  the  terminal.  Only 
one  path  to  the  terminal  may  do  10  operations  at  a  time,  and  this  path 
is  specified  by  the  value  of  the  Vifunction  'FCAcurrentPath(t)' ,  where 
t  refers  to  the  terminal  group  or  physical  terminal. 

The  different  paths  associated  with  a  particular  physical  terminal 
are  specified  by  the  value  of  the  V1function  'FCAterminalPathSet (c) ' , 
where  t  is  as  above.") 

$("  EXTENTS  11  Extents  are  addressable  devices,  representing  areas  on  a 

disk,  with  a  block  size  of  512  and  a  size  determined  when  the  device  is 
physically  mounted.  For  the 

purposes  of  this  specif ication,  the  size  has  been  predetermined,  as  no 
physical  mounting  is  specified.  The  special  property  of  extents  is  that 
they  can  be  logically  mounted,  so  that  they  'become'  a  file  system 
or  set  of  files.  When 

the  system  is  started  up,  there  are  no  files,  except  the  root,  only 
extents.  Each  extent  is  mounted,  setting  up  the  actual  file  system 
that  a  user  sees  when  he  logs  on.  When  the  extent  is  mounted,  it  can 
no  longer  be  accessed  as  an  extent.  Unmounting  turns  a  file  system 
back  into  an  extent,  and  the  file  system  disappears.") 

$("  FILES  *4  Files  are  addressable  devices,  with  a  block  size  of  512  and 
two  important  properties.  They  can  be  dynamically  created  and  deleted, 
and  they  are  of  variable  si2e.  Writing  onto  the  end  of  a  file  effectively 
changes  its  size.  Files  may  also  be  linked  to.  A  link  is  a  reference 
count  used  by  the  directory  manager  sitting  above  the  kernel.  It 
represents  the  number  of  directories  in  which  a  file  is  found.  When 
this  count  goes  to  0,  and  no  process  has  the  file  open,  the  file 
is  deleted.  This  is  the  only  way  of  deleting  files,  although  they  can 
be  explicitly  created.") 

$("  SUBTYPES  **  This  is  an  additional  protection  mechanism  over  and  above 
that  provided  by  the  mandatory,  privilege,  and  discretionary  access 
control  systems.  Each  openable  object  may  be  associated  with  a 
subtype,  of  which  there  are  a  fixed  number  at  system  generation  time. 

Any  object  of  a  non,null  subtype  may  be  accessed  only  by  those  processes 
who  have  access  rights  to  the  subtype  as  well  as  the  object.  The 
access  right  to  a  subtype  is  established  by  opening  the  subtype  for 
the  desired  access.  Access  to  the  subtype  is  granted  or  denied  according 
to  the  usual  mandatory  and  discretionary  rules.  An  object  with 
a  non'null  subtype  can  be  accessed  only  when  the  open  descriptor  for 
the  subtype,  to  which  access  must  already  have  been  granted,  is 
presented,  and  when  the  desired  access  to  the  object  is  a  subset  of 
the  access  granted  to  the  subtype.  This  forms  a  miniJcapability 
mechanism  with  type  extention,  which  is  necessary  for  achieving  access 
control  over  objects  such  as  directories.  Thus  there  will  be  a 
directory  subtype,  to  prevent  arbitrary  programs  from  damaging  the 
directory  system  just  because  they  have  access  to  a  particular 
directory.  The  rules  for  subtype  access  occur  in  the  open  function  and 


Version  4.4 


-78- 


WDL-TR7932 


fca. specs  Page  3 


Wed  Mar  18  11:11:10  1981 


113  all  functions  that  require  a  subtype  capability  for  accessing 

114  an  object.") 

115 

116 

117  TYPES 

118 

119  $ (FROM  smx) 

120  nonDlsType :  STRUCT_0F( 

121  INTEGER  securityLevel ;  SET_0F  securityCat  securityCatS ; 

122  INTEGER  integrityLevel ;  SET_0F  integrityCat  integrityCatS ) ; 

123  daType:  SETOF  daMode ; 

124  modeStruct:  STRUCT_0F( daType  ownerMode,  groupMode,  allMode); 

125  tiiStruct:  STRlICT_OF(nonDisType  nd ;  modeStruct  ms;  INTEGER  owner,  group; 

126  SET_0F  privType  priv); 

127 

128  $(from  fca  11  exportable) 

129  openDescriptor :  DESIGNATOR; 

130  openModes :  {omRead,  omWrite,  omExclusiveRead ,  omExclusiveWrite} ; 

131  IOfunction:  {rewind,  etc};  $(names  for  special  kinds  of  10  functions) 

132  deviceType:  {RK05,  RWP04,  RWP05 ,  RWP06 ,  RSW04 ,  TWE16,  TM11,  TU56,  PR11, 

133  PC11,  LP11,  IMP 1 1 B ,  LHDH } ; 

134  terminalGroup :  DESIGNATOR; 

135  fileNsp:  {129  ..255};  $(nsp  values  for  file  systems) 

136 

137  $(from  fca  11  redeclarable) 

138  fileStatus:  STRUCT_0F( INTEGER  nBlocks,  linkCount,  timeLastMod; 

139  seid  subtype;  BOOLEAN  openAtCrash) ; 

140  $(data  about  an  openable  object  that  is  returned  to  the  user) 

141  global Data:  STRUCT_0F( INTEGER  linkCount,  openCount ,  timeLastMod;  seid  subtype; 

142  BOOLEAN  openAtCrash); 

143  $(state  information  for  all  openable  objects) 

144  fileBlock:  VECT0R_0F  CHAR; 

145  ioStatus:  STRUCT_0F( INTEGER  devlndep,  devDep); 

146  $(result  of  an  10  operation.  Including  possible  hardware  failure)  ^ 

147  openFileEntry :  STRUCT_0F(seId  openSeid;  SET_0F  openModes  openMode); 

148  $(entry  in  a  process'  open  file  table) 

149  asyncld:  CHAR; 

150  readResult:  STRUCT_OF(VECTOR__OF  fileBlock  data;  ioStatus  errst); 

151  deviceStruct :  STRUCT_0F (BOOLEAN  addressable; 

152  INTEGER  minRequest,  maxRequest,  modSize,  maxBlockNo); 

153  $(properties  necessary  for  processing  10  requests  for  devices) 

154  mountTableEntry :  STRUCT_0F(seid  devSeid;  BOOLEAN  readonly; 

155  tiiStruct  devTii;  globalData  devGl); 

156  f ileSystemEntry :  STRUCT_0F(seid  fileSeid;  globalData  gl;  tiiStruct  til; 

157  VECT0R_0F  fileBlock  fileData); 

158  $(the  state  of  a  file,  for  purposes  of  mounting  and  unmounting) 

159  fileSystem:  SET_0F  f ileSystemEntry; 

160  $(the  state  of  an  entire  mountable  file  system) 

161  sodPair:  STRUCT_0F(seid  ps ;  openDescriptor  od); 

162  $(for  openCount  definition) 

163 

164 

165  PARAMETERS 

166 

167  SET_0F  seid  subtypeSeidSet ;  $(  set  of  non*null  subtypes  known  to  the  systsm) 

168  seid  nullStSeid;  $(  seid  indicating  the  null  subtype) 
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169  openDescriptor  FCAnullSt;  $(a  file  descriptor  indicating  the  null  subtype) 

170  seid  FCArootSeid;  $(distinguished  root  of  KSOS  permanent  file  system) 

171  INTEGER  FCAmaxOpenDescriptors ;  $ (maximum  number  of  open  descriptors  per 

172  process ) 

173 

174 

175  DEFINITIONS 

176 

177  INTEGER  FCAf ileSize(seid  fSeid)  IS 

178  CARDINALITY( { INTEGER  i  1  FCAfileData(fSeid,  l)  ?}); 

179  $(the  size,  in  blocks,  of  an  addressable  device,  file,  or  extent) 

180 

181  INTEGER  nOpenDescriptors (seid  pSeid)  IS 

182  CARDINALITY( {openDes cr iptor  od  I  FCAopen£ntry(pSeid,  od)  ~=  ? } ) ; 

183  $(the  number  of  open  objects  in  a  given  process;  it  must  not  exceed  a  fixed 

184  maximum) 

185 

186  deviceStruct  deviceDataSeid(seld  fSeid)  IS 

187  DDFdeviceData(FCAdeviceType (fSeid )) ; 

188  $(given  the  seid  of  a  device,  the  data  on  which  its  10  requests  depend) 

189 

190  SET_OF  daMode  h_modeTrans  (SET_0F  openModes  oModes )  IS 

191  (IF  omRead  INSET  oModes  THEN  {daRead}  ELSE  {}) 

192  UNION  (IF  omWrite  INSET  oModes  THEN  {daWrite}  ELSE  {}); 

193  $(translates  from  one  enumerated  type,  open  Modes,  to  another  slightly 

194  different  enumerated  type,  discretionary  access  modes) 

195 

196  BOOLEAN  isCurrentPath(seid  tSeid)  IS 

197  EXISTS  terminalGroup  t  :  FCAcurrentPath(t )  =  tSeid; 

198  $(for  a  given  terminal,  tells  whether  it  is  the  active  path  to  its  physical 

199  device) 

200 

201  BOOLEAN  isReadOnly(seid  s)  IS 

202  EXISTS  fileNsp  fsNsp 

203  :  SEN8eidNsp(FCAmountTable(fsNsp).devSeid)  *  SENseidNsp(s ) 

204  AND  FCAmountTable (fsNsp). readonly  »  TRUE; 

205  $(tells  whether  or  not  a  given  file  is  on  a  file  system  that  is  mounted  in 

206  read*only  mode) 

207 

208  $(When  a  file's  link  count  goes  to  zero,  its  link  count  becomes  '?',  which 

209  means  that  it  does  not  exist  for  any  operation,  Including  K_link.  The 

210  file  cannot  be  physically  deleted  until  its  open  count  becomes  zero,  though.) 

211 

212  BOOLEAN  logicalFileExis tence (seid  fSeid)  IS 

213  FCAinfo(fSeid)  “=  ?  AND  FCAinfo(fSeid). linkCount  ?; 

214 

215  EXTERN ALREFS 

216 

217  FROM  mac : 

218  VFUN  MACclockO  J>  INTEGER  time; 

219 

220  FROM  smx: 

221  seid:  DESIGNATOR; 

222  secureEntityType:  {tFile,  tDevice,  tTerminal,  tProcess ,  tSegment,  tSubtype, 

223  tExtent,  tNull}; 

224  privType:  { 
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prl vFlleUpdateStatus ,  privLink, 
prlvLockSeg,  privModlf yPriv, 

privMount,  privSetLevel, 

privStickySeg,  privSetPath, 

prlvVlolSlmpSecurlty,  privViolStarSecurity, 
privViolSimpIntegrity,  privVlolStar Integrity, 
privViolDiscr Access ,  privRealizeExecPermisslon, 
privSignal,  privWalkPTable, 

privHalt,  privKernelCall , 

privViolCompartments ,  privSetComm, 


1 


privSignal, 
privHalt , 

privViolCompartments 
prl vlmmigrate 
}; 


238  daMode:  {daRead,  daWrite,  daExecute}; 

239  securityCac:  DESIGNATOR; 

240  integrityCat:  DESIGNATOR; 

241  VFUN  SENseidNsp(seid  s)  *>  INTEGER  nsp; 

242  VFUN  SENseidType (seid  s)  J>  secureEntityType  set; 

243  VFUN  Tllinf o(seid  s)  ■>  tiiStruct  tiist; 

244  VFUN  SMXhasPriv(seid  pSeid;  privType  priv)  *>  BOOLEAN  b; 

245  VFUN  SMXf low(seid  pSeid,  oSeid;  daType  d)  *>  BOOLEAN  b; 

246  VFUN  SMXdap(seid  pSeid,  oSeid;  daType  d)  *>  BOOLEAN  b; 

247 

248  FROM  ddf : 

249  VFUN  DDFdeviceData(deviceType  d)  *>  deviceStruct  ds ; 

250 


$ (DDFdeviceData ) 


253  ASSERTIONS 

254 

255  FORALL  seid  s;  openDescriptor  od 

256  :  SMXf low(s ,  FCAopenEntry(s ,  od ).openSeid,  {daRead}); 

257  $(FCAopenEntry  only  contains  seids  of  objects  whose  security 

258  levels  are  lower  than  that  of  the  opening  process) 

259 

260  FORALL  seid  pSeid; 

261  openDescriptor  od  |  FCAopenEntry(pSeid ,  od)  ~m  ?; 

262  openFileEntry  oe  »  FCAopenEntryCpSeid ,  od) 

263  :  (omWrite  INSET  oe.openMode 

264  AND  SENseidType(oe.openSeid)  “»  tSubtype) 

265  »>  SMXf low(pSeid,  oe.openSeid,  {daRead,  daWrite}); 

266  $(  any  object  open  for  reading  and  writing  that  is  not  a  subtype 

267  must  be  at  the  same  security  level  as  the  process  that  opened 

268  it) 

269  FORALL  seid  pSeid; 

270  openDescriptor  od  I  FCAopenEntry(pSeid,  od)  ?; 

271  openFileEntry  oe  -  FCAopenEntry(pSeid ,  od ) 

272  :  {omExclusiveRead,  omExclus i veWrite }  SUBSET  oe.openMode 

273  »>  SMXf low(pSeid,  oe.openSeid,  {daRead,  daWrite}); 

274  $(all  files  open  for  exclusive  use  are  open  only  by  processes  of 

275  the  same  security  level) 

276 

277  FORALL  seid  s  |  FCAinfo(s)  ~=  ?  AND  FCAinfo(s ). subtype  "■  nullStSeid 

278  :  SMXflow(s,  FCAinfo(s ). subtype ,  {daRead}); 

279  $(  the  level  of  a  subtype  is  less  than  or  equal  to  the  levels 

280  of  any  objects  of  that  subtype) 
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281 

282  FORALL  seid  fSeid  |  FCAinfo(fSeid)  ? 

283  :  SENseidType(fSeid)  INSET  {tTermlnal,  tDevlce,  tSubtype,  tFile,  tExtent}; 

284  $(restricts  the  types  of  objects  manipulated  by  this  module) 

285 

286  FORALL  seid  fSeid:  {INTEGER  i  |  FCAf ileData(f Seid,  i)  ?} 

287  -  {0  ..  FCAf ile Size (fSeid)  4  1}; 

288  $(the  blocks  of  a  file,  extent,  or  addressable  device  form  a  sequence) 

289 

290  FORALL  seid  dSeid 

291  |  SENseidType (dSeid )  =  tDevice  AND  FCAinf o(dSeid)  *-  ? 

292  :  (LET  deviceStruct  d  -  de viceDataSeid(dSeid) 

293  IN  NOT  d.  addressable  *=>  d.modSize  **  1  AND  d.maxBlockNo  »  0); 

294  $(necessary  properties  of  all  non4addressable  devices) 

295 

296  FORALL  seid  fSeid 

297  |  FCAinfo(fSeid)  ~=  ? 

298  :  (LET  secureEntityType  t  =»  SENseidType(f Seid) 

299  IN  FORALL  INTEGER  i  |  FCAfileData(fSeid,  i)  ? 

300  :  LENGTH (FCAf ile Data (fSeid,  i)) 

301  =  (IF  t  =  tDevice  THEN  deviceDataSeid (fSeid). modSize 

302  ELSE  IF  t  INSET  {tExtent,  tFile}  THEN  512 

303  ELSE  ?)); 

304  $(the  lengths  of  all  blocks  for  files,  extents,  or  addressable  devices 

305  must  correspond  to  the  paremeters  for  those  objects) 

306 

307  FORALL  seid  s  |  SENseidType(s )  =  tTermlnal  AND  FCAinfo(s)  “■  ? 

308  :  (EXISTS  terminalGroup  tl 

309  :  s  INSET  FCAterminalPathSet (t 1 ) 

310  AND  (FORALL  terminalGroup  t2  tl 

311  :  NOT  s  INSET  FCAterminalPathSet (t2)) ) ; 

312  $(each  terminal  is  in  exactly  one  terminal  group) 

313 

314  FORALL  seid  f 

315  I  EXISTS  INTEGER  i  :  FCAf ileData (f ,  i)  ? 

316  :  FCAinf o(f)  ? 

317  AND  ( SENseidType (f)  ■  tDevice  AND  devlceDataSeld(f). addressable  *  TRUE 

318  OR  SENseidType (f)  INSET  {tFile,  tExtent}); 

319  $(only  files,  extents,  or  addressable  devices  have  file  data) 

320 

321  FORALL  seid  f 

322  :  (FCAinputStream(f )  ?  AND  FCAoutputStream(f )  “■  ?) 

323  -  (SENseidType(f )  -  tTermlnal 

324  OR  SENseidType(f )  ■  tDevice 

325  AND  deviceDataSeid(f). addressable  -  FALSE); 

326  $(non4addressable  device  have  both  an  input  and  an  output  stream,  although 

327  it  may  always  be  null) 

328 

329  FORALL  seid  pSeid  |  FCAopenTableExis ts (pSeid) 

330  :  FCAopenEntry(pSeid,  FCAnullSt)  ■  7; 

331  $(there  are  never  any  opened  objects  assigned  to  the  open  descriptor 

332  reserved  for  the  null  subtype) 

333 

334  FORALL  seid  si;  seid  s2 

335  :  SENseidType (s 1)  ■  tSubtype  AND  SENse^dType(s2)  ■  tSubtype 

336  ■>  SENseidNsp(s 1 )  ■  SENseidNsp(s2); 
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337  $(subcypes  have  only  one  name  space  partition) 

338 

339  SENseidType(nullStSeid)  »  tSubtype; 

340  $(the  null  subtype  seid  is  a  subtype  ) 

341 

342  FORALL  seid  s  INSET  subtypeSeidSet  :  SENseidType(s )  ■  tSubtype; 

343  $(properties  of  the  set  of  non*null  subtypes) 

344 

345  SENseidType(FCArootSeid)  »  tFile; 

346  $(property  of  the  distinguished  root  of  the  entire  file  system) 

347 

348  FORALL  seid  f  |  FCAinfo(f)  ?  AND  SENseidType (f )  -  tFile 

349  : EXISTS  fileNsp  fsNsp  :SENseldNsp(FCAmountTable(fsNsp).devSeid) 

350  -  SENseidNsp (f ) 

351  OR  f  »  FCArootSeid ; 

352  $(a  file  is  either  the  root  or  it  is  on  a  mountable  file  system) 

353 

354 

355  FUNCTIONS 

356 

357  5(<»iiiniimiiiniiii  state  functions  11  devices 

358 

359  VFUN  FCAdeviceType(seid  fSeid)  *>  deviceType  d;  $(FCAdeviceType ) 


360  $ (gives  the  type  of  a  particular  device,  which  determines  its  10  behavior) 

361  HIDDEN; 

362  INITIALLY 

363  (d  ?) 

364  ---  (SENseidType (fSeid)  -  tDevice  AND  FCAinf o(f Seid)  ?); 

365 

366  $(«*****»*•***»**»****»*•«  state  functions  **  terminals  mm'iiminiiin) 

367 

368  VFUN  FCAterminalPathSet(terminalGroup  t)  *>  SETjDF  seid  ss ; 

369  $(FCAterminalPathSet ) 

370  $(defines  the  set  of  paths,  or  logical  terminals,  that  correspond  to 

371  a  given  terminal  group,  or  physical  terminal) 

372  HIDDEN; 

373  INITIALLY 

374  FORALL  seid  s  INSET  ss 

375  :  FCAinf o(s)  ?  AND  SENseidType (s )  -  tTerminal ; 

376 

377  VFUN  FCAcurrentPath(terminalGroup  t)  *>  seid  s;  $ (FCAcurrentPath) 

378  $(the  seid  of  the  logical  terminal  that  is  allowed  to  do  10  on  a  given 

379  physical  terminal) 

380  HIDDEN; 

381  INITIALLY 

382  s  INSET  FCAterminalPathSet (t ) ; 

383 

384  $(*••»*•»»**••*»»»•«•  state  functions  11  mountable  file  systems  *»••••••»••*) 

385 

386  VFUN  FCAmountTable(fileNsp  fsNsp)  J>  mountTableEntry  mte;  $(FCAmount Table) 

387  $(for  a  given  extent  that  is  mounted,  tells  leaf  of  the  old  file  system, 

388  the  root  of  the  new  or  mounted  file  system,  whether  the  file  system 

389  is  read  only,  and  the  state  information  for  the  extent) 

390  HIDDEN; 

391  INITIALLY  mte  -  ?; 

392 
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393  VFUN  FCAextentToFileSys (VECT0R__0F  fileBlock  fb;  seid  rootSeld) 

394  *>  flleSystem  fs ;  $(FCAextentToFileSya ) 

395  $(given  the  data  of  a  given  extent  and  a  root  seid  for  a  file  system 

396  to  be  made  out  of  the  extent  whose  data  is  given,  produces  the 

397  file  system,  consisting  of  a  set  of  tuples  each  made  up  of  a 

398  file  seid  and  the  state  of  the  file) 

399  HIDDEN; 

400  INITIALLY 

401  fs  ~=  ?  => 

402  (EXISTS  f ileSystemEnt ry  fse  INSET  fs  :  rootSeid  =  fse. fileSeid) 

403  AND  (F0RALL  f ileSystemEntry  fse  INSET  fs 

404  :  SENseidNsp(fse . fileSeid  )  m  SENseidNsp(rootSeid)) ; 

405  $(a  constant  function  for  data  conversion) 

406 

407  5(*'iniiiiiiimnn  state  functions  41  files  4,1  *  iniiimi ) 

408 

409  VFUN  FCAinfo(seid  fSeid)  4>  globalData  gl ;  $(FCAinfo) 

410  $(the  status  information,  excluding  data  and  type  dependent  stuff,  for 

411  an  openable  object) 

412  HIDDEN; 

413  INITIALLY 

414  IF  deviceDataSeid(fSeid)  ~=  ?  THEN  gl  ~=  ? 

415  ELSE  IF  fSeid  INSET  {FCArootSeid,  nullStSeid} 

416  THEN  gl. subtype  =  nullStSeid 

417  ELSE  IF  fSeid  INSET  subtypeSeidSet  THEN  gl. subtype  -  nullStSeid 

418  ELSE  gl  -  ?; 

419 

420  VFUN  FCAf ileData (seid  fSeid;  INTEGER  blockNo)  4>  fileBlock  fb;  $(FCAf ileData) 


421  $(the  data  contained  on  a  file,  extent  or  an  addressable  device) 

422  DEFINITIONS 

423  secureEntityType  type  IS  SENseidType(f Seid ) ; 

424  deviceStruct  d 

425  IS  IF  type  »  tDevice  THEN  deviceDataSeid(f Seid) 

426  ELSE  IF  type  INSET  {tFile,  tExtent} 

427  THEN  STRUCT (TRUE,  512,  65534,  512,  FCAfileSize(fSeid)'l) 

428  ELSE  STRUCT( FALSE ,  1,  255,  1,  0); 

429  HIDDEN; 

430  INITIALLY 

431  (IF  FCAinf o(f Seid)  -  ?  OR  type  INSET  {tTerminal,  tSubtype} 

432  OR  NOT  blockNo  INSET  {0  ..  d.max31ockNo}  OR  NOT  d. addressable 

433  THEN  fb  -  ? 

434  ELSE  fb  ?) 

435  AND  (fb  ? 

436  ->  LENGTH (fb)  =  d.modSize 

437  AND  (F0RALL  INTEGER  i  INSET  {0  ..  blockNo  4  1} 

438  :  FCAf ileData (fSeid,  i)  ?) 

439  AND  (F0RALL  INTEGER  j  INSET  {1  ..  LENGTH(fb)} 

440  :  fb[j]  ?)); 

441 


442  VFUN  FCAinput Stream (seid  fSeid)  4>  VECT0R_0F  CHAR  vc;  $ (FCAinputStream) 

443  $(the  input  data  for  terminals  and  nonaddress  able  devices) 

444  HIDDEN; 

445  INITIALLY 

446  IF  FCAinf o(fSeid)  ? 

447  AND  (SENseidType(fSeid)  ■  tTerminal 

448  OR  SENseidType(fSeid)  *  tDevice 
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449  AND  deviceDataSeid(f Seid) . addressable  «  TRUE) 

450  THEN  vc  ? 

451  ELSE  vc  -  ? ; 

452 

453  VFUN  FCAoutputStream(seid  fSeid)  *>  VECTOR_OF  CHAR  vc;  $(FCAoutputStream) 

454  $(the  output  data  for  terminals  and  nonaddressable  devices) 

455  HIDDEN; 

456  INITIALLY 

457  IF  FCAlnf o(fSeld)  ? 

458  AND  (SENseidType(fSeid)  =  tTerminal 

459  OR  SENseidType (fSeid )  »  tDevlce 

460  AND  devlceDataSeld(fSeld). addressable  ■  TRUE) 

461  THEN  vc  ? 

462  ELSE  vc  »  ?; 

463 

464  5(<«ininminnnmiii  state  functions  *'  open  tables  ******************) 

465 

466  VFUN  FCAopenTableExists (seld  pSeid)  *>  BOOLEAN  b;  $(FCAopenTableExlsts ) 

467  $(the  existence  predicate  for  the  table  of  openable  objects  corresponding 

468  to  a  given  process) 

469  HIDDEN; 

470  INITIALLY  b  -  FALSE; 

471 

472  VFUN  FCAopenEncry(seid  pSeid;  openDescriptor  od)  *>  openFlleEnt ry  oe; 


473 

$(the  Information 

In  entry  "od"  of  the  open  table  of 

process  "pSeid") 

474 

HIDDEN; 

$(FCAopenEntry) 

475 

INITIALLY  oe  =■  ?; 

476 

477 

478 

5(1111111111.111111! 

**  creation  of  files  ***»»•»»»»*»* 

479  OVFUN  FCAcreate(seld  pSeid,  nspSeid;  SETjOF  openModes  mode;  modeStruct  d;  openDescriptor  sf 

480  *>  STRUCT_OF(seid  fSeid;  openDescriptor  od)  return;  $(FCAcreate) 

481 

482  $(creates  a  file  and  opens  it  In  the  desired  mode,  the  file  system  on 
433  which  the  file  resides  must  be  writable.  If  a  subtype  capability 

484  Is  provided,  It  must  refer  to  a  valid  subtype.  The  created  file  gets 

485  only  the  discretionary  access  permission  specified.  All  other  data 

486  comes  from  the  process  making  the  call.  The  file  is  originally  of  zero 

487  length) 

488  DEFINITIONS 

489  tiiStruct  ptii  IS  Tllinf o(pSeid) ; 

490  tiiStruct  otil  IS  STRUCT(ptii.nd,  d,  ptii. owner,  ptii. group,  ptii.prlv); 

491  seid  extSeld 

492  IS  SOME  seid  s  |  SENseldNsp(FCAmountTable(SENseldNsp(s )).devSeld) 

493  *  SENseidNsp(nspSeid) ; 

494  EXCEPTIONS 

495  $(these  exceptions  subsume  those  for  opening  a  file  for  writing) 

496  XbadModes :  NOT  ((mode  *  {omRead}) 

497  OR  (mode  ■  {omWrite}) 

498  OR  (mode  »  {omRead,  omWrite}) 

499  OR  (mode  ■  {omRead,  omWrite,  omExclusiveWrlte}) 

500  OR  (mode  -  {omRead,  omWrite,  omExclusiveRead,  omExclusiveWrlte})); 

501  XbadStCap: 

502  stCap  FCAnullSt  AND  SENseidType(FCAopenEntry(pSeid,  stCap).openSeid)  "■  tSubtype; 

503 

504  XodSpace:  nOpenDescrlptors(pSeld)  >■  FCAmaxOpenDescriptors ; 
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505 

506 

507 

508 

509 

510 

511 

512 

513 

514 

515 

516 

517 

518 

519 

520 

521 

522 

523 

524 

525 

526 

527 

528 

529 

530 

531 

532  $(,J  i  m»  n  •  1 1  •  n  n  *  1 1 1 1 «  t  fne  opening  and  closing  <'imimiunniiiiiii) 

533 

534  OVFUN  FCAopen(seid  pSeid,  o;  SET_0F  openModes  mode;  oper.Descriptor  stCap) 

535  *>  openDescriptor  od;  $(FCAopen) 

536  $(opens  the  openable  object  specified  by  "o".  The  object  must  exist 

537  and  the  process  "pSeid"  must  have  the  right  mandatory  and  discretionary 

538  access.  Special  rules,  described  below,  apply  to  subtypes. 

539  Special  rules  also  apply  when  the  object  is  being  opened  for  exclusive 

540  use.  Only  one  process  may  open  an  object  for  exclusive  use. 

541  A  process  is  allowed  a  fixed  maximum  number  of  open  objects.) 

542  DEFINITIONS 

543  globalData  ofst  IS  FCAinfo(o); 

544  openFileEntry  stEntry  IS  FCAopenEntry(pSeid,  stCap); 

545 

546  EXCEPTIONS 


547 

XbadModes : 

NOT 

((mode  “  {omRead})  $(  bad  user  argument  ) 

548 

OR 

(mode  *  {omWrite}) 

549 

OR 

(mode  ■  {omRead,  omWrite}) 

550 

OR 

(mode  *  {omRead,  omWrite,  omExclusiveWrite}) 

551 

OR 

(mode  *  {omRead,  omWrite,  omExclusiveRead,  omExclusiveWrite})); 

552 

553 

XbadStCap : 

$(  bad  subtype  od  given  ) 

554  stCap  FCAnullSt  AND  SENseidType(stEntry.openSeid)  tSubtype; 

555  $(a  subtype  capability  was  specified,  but  it  is  not  for  a  valid  subtype) 

556 

557  XodSpace:  nOpenDescriptors(pSeid)  >»  FCAmaxOpenDescriptors ; 

558  $(  no  open  descriptors  left  ) 

559 

560  XnoFile:  (ofst  **  ?)  $(  inaccessable  ) 


XnoFile:  $(  actually  means  no  file  system  ) 

NOT(extSeid  ~m  ?  AND  SMXf low(pSeid ,  extSeid,  {daRead})); 

$(the  flow  violation  applies  to  the  file  system  on  which  the  newly 
created  file  is  to  reside;  its  TII  exists  but  not  its  global  data) 
XnotWri table :  is  Readonly (ns p Seid ) ; 

XbadSubtype:  $(  NOT  currently  checked  in  Implementation  JN) 

stCap  ~=  FCAnullSt 

AND  NOT  omWrite  INSET  FCAopenEntry(pSeid,  s tCap ) . openMode ; 
RES0URCE_ERR0R; 

ASSERTIONS 

FCAopenTabieExis  ts (pSeid ) ; 

SMXf low(pSeid ,  nspSeid,  {daRead}); 

EFFECTS 

LET  seid  fs  |  FCAinfo(fs)  =  ?; 

openDes cr iptor  o  |  FCAopenEntry(pSeid ,  o)  =  ? 

AND  o  FCAnullSt 

AND  SENseidType (fs )  =  tFile 

AND  SENseidNsp  (fs)  =  SENseidNsp(nspSeid) 

IN  'TIIinfo(fs)  -  otil 

AND  'FCAoper.Ent  ry(pSeid ,  o)  =  STRUCT(fs,  mode) 

AND  return  =  STRUCT(fs,o) 

AND  'FCAinfo(fs)  -  STRUCT(0,  1,  MACclock(), 

IF  stCap  =  FCAnullSt  THEN  nullStSeid 

ELSE  FCAopenEntry(pSeid,  stCap). openSeid, 
FALSE); 
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561 

562 

563 

564 

565 

566 

567 

568 

569 

570 

571 

572 

573 

574 

575 

576 

577 

578 

579 

580 

581 

582 

583 

584 

585 

586 

587 

588 

589 

590 

591 

592 

593 

594 

595 

596 

597 

598 

599 

600 
601 
602 

603 

604 

605 

606 

607 

608 


OR  (omRead  INSET  mode  AND  NOT  SMXf low(pSeid,  o,  {daRead  })) 

OR  (omWrite  INSET  mode  AND  NOT  SMXf low(pSeid,  o,  {daWrlte})) 

OR  (SENseidType(o)  =  tFile  AND  NOT  logicalFlleExistence(o)) ; 

$(  discretionary  access  ck  ) 
XdapViol:  NOT  SMXdap(pSeid ,  o,  h_modeTrans (mode) ) ; 

XbadSubtypel: 

stCap  *  FCAnullSt  AND  NOT  ofst. subtype  =  nullStSeid; 

$(no  subtype  capability  was  specified,  but  the  object  has  a  non*null 
subtype) 

XbadSubtype2 :  $(  unwanted  subtype  seid  ) 

stCap  ~=  FCAnullSt  AND  ofst. subtype  =  nullStSeid; 

XhadSubtype3 : 

stCap  ~=  FCAnullSt 

AND  (stEntry. openSeid  “=  ofst. subtype  $(  wrong  subtype  ) 

OR  NOT  (  $(  open  modes  must  be  subset  of  subtype  modes) 

(mode  INTER  {omRead,  omWrite}) 

SUBSET  (stEntry. openMode  INTER  {omRead,  omWrite}) 

) 

); 

$(a  subtype  capability  is  specified,  but  it  does  not  match  the  subtype 
of  the  object,  with  access  modes  included; 

note  that  execute  mode  on  the  subtype  is  required  to  write  on 
an  object  of  the  subtype) 

XnotWritable :  omWrite  INSET  mode  AND  isReadOnly(o) ; 

Xbusy:  $(  exclusive  use  conflict  ) 

EXISTS  seid  pSeidl;  openDes criptor  odl. 

FCAopenEntry(pSeidl,  odl). openSeid  ■  o  AND 
(  (omRead  INSET  mode 

AND  omExclusiveRead  INSET  FCAopenEntry (pSeidl , odl). openMode) 

OR  (omWrite  INSET  mode 

AND  omExclusiveWrite  INSET  FCAopenEntry(pSeid 1 , odl ). openMode ) 

OR  (omExclusiveRead  INSET  mode 

AND  omRead  INSET  FCAopenEntry(pSeidl , odl). openMode) 

OR  (omExclusiveWrite  INSET  mode 

AND  omWrite  INSET  FCAopenEntry(pSeidl , odl ) .openMode ) 

); 

ASSERTIONS 

FCAopenTableExis ts (pSeid); 

EFFECTS 

LET  openDescriptor  odl  |  FCAopenEntry(pSeid,  odl)  ■  ?  AND  odl  ”*  FCAnullSt 
IN  'FCAopenEntry(pSeid,  odl)  *  STRUCT(o,  mode) 

AND  od  =*  odl; 

'FCAinfo(o)  »  STRUCT(ofst . linkCount ,  ofs t. openCount  +  1, 

ofst. timeLastMod,  ofs t. subtype ,  ofst.openAtCrash) ; 


609  OFUN  FCAclose(seid  pSeid;  openDescriptor  od);  $(FCAclose) 

610  ^(closes  the  open  object  named  by  "od".  If  the  object  is  not  is  use  by 

611  anyone  else,  either  by  linking  or  by  opening,  then  the  object  is  deleted) 

612  DEFINITIONS 

613  openFileEntry  oe  IS  FCAopenEntry(pSeid,  od); 

614  seid  fSeid  IS  oe. openSeid; 

615  globalData  ofst  IS  FCAinf o(f Seid ) ; 

616  EXCEPTIONS 
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617 

618 

619 

620 
621 
622 

623 

624 

625 

626 

627 

628 

629 

630 

631 

632 

633 

634 

635 

636 

637 

638 

639 

640 

641 

642 

643 

644 

645 

646 

647 

648 

649 

650 

651 

652 

653 

654 

655 

656 

657 

658 

659 

660 
661 
662 

663 

664 

665 

666 

667 

668 

669 

670 

671 

672 


XbadOd :  oe  =  ? ; 

ASSERTIONS 

FCAopenTableExis ts ( pSeld  )  ; 

EFFECTS 

IF  (ofs t . linkCount  3  0  OR  ofs t. linkCount  «  ?) 

AND  ofst. openCount  *  l 
AND  SENseidType (f Seld )  =  tFile 
THEN  'FCAinfo('fSeid)  =■  ? 

AND  (F0RALL  INTEGER  i  :  'FCAfi leData (f Seid ,  i)  -  ?) 

AND  'TIIinfo(fSeid)  =  ? 

ELSE  ' FCAinf o( f Seid )  =  STRUCT(ofst . linkCount ,  ofs t. openCount  ‘  1, 

ofst. timeLastMod ,  of st . subtype , 
ofs  t . openAtCrash ) ; 

' FCAopenEnt ry (pSeld ,  od  )  =  ?; 

$(the  openAtCrash  field  is  cleared  when  closing  an  object  that  was  open 
for  writing.  This  has  not  been  put  in.) 

^iiiiiniiiiiminiiniiiii  open  table  maintenance  “  mmniiim  *  *•*»•* ) 

OFUN  FCAcreateOpenTable(seid  pSetd);  $(FCAcreateOpenTable ) 

$(  this  operation  creates  an  open  table  associated  with  a  process  seid; 
it  is  used  as  an  auxiliary  operation  by  the  process  modules  when 
creating  a  new  a  process) 

ASSERTIONS 

NOT  FCAopenTableExists (pSeld)  ; 

EFFECTS 

'FCAopenTableExists (pSeld)  =  TRUE; 

OFUN  FCAdeleteOpenTable (seid  pSeid);  $(FCAdeleteOpenTable ) 

$(  Deletes  the  open  table  associated  with  a  process;  supports  the  release 
of  a  process) 

ASSERTIONS 

FCAopenTableExists (pSeid ) ; 

EFFECTS 

'FCAopenTableExis ts (pSeid )  =  FALSE; 

^iiiiiiiiiiiiiiiiiiiinii  utility  operations 

OFUN  FCAcopyOpenTable(seid  fromSeid,  toSeid);  $ (FCAcopyOpenTable ) 

$(Copies  the  contents  of  one  open  table,  "fromSeid,"  to  another,  "toSeid." 

"toSeid"  must  be  empty) 

ASSERTIONS 

FCAopenTableExists (fromSeid); 

FCAopenTableExists (toSeid ) ; 

FORALL  openDescriptor  od  :  FCAopenEnt ry( toSeid ,  od)  «  ?; 

EFFECTS 

FORALL  openDescriptor  od; 

seid  fSeid  =  FCAopenEntry(fromSeid,  od ) . openSeid ; 
globalData  ofst  -  FCAlnfo(fSeid) 

:  'FCAopenEntry(toSeid,  od )  =»  FCAopenEntry(f romSeid ,  od) 

AND  (ofst  ? 

->  'FCAinfo(fSeid) 

=  STRUCT(ofst . linkCount ,  of st . openCount  +  1, 
of st . timeLastMod ,  ofst .subtype , 
ofst. openAtCrash)) ; 
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673  5(»<*“<uiiiuiiinnmi  file  status  operations  »***«*»<*,|**1,||1***,|1“) 

674 

675  VFUN  FCAgetFileStatus (seld  pSeid,  fSeid)  *>  fileStatus  fst ; $(FCAgetFileStatus ) 

676  $(retums  the  status  of  the  file.  The  requesting  process  must  have 

677  mandatory  access  to  the  object,  and  the  object  must  exist) 

678  DEFINITIONS 

679  seid  f  IS  fSeid; 

680  globalData  gl  IS  FCAinfo(f); 

681  EXCEPTIONS 

682  XnoFile :  NOT(FCAinf o(f )  ?  AND  SMXflow( pSeid ,  f,  {daRead})); 

683  DERIVATION 

684  STRUCT( IF  FCAf ileSize(f )  =  ?  THEN  0  ELSE  FCAf ileSize(f ), 

685  gl . linkCount ,  gl . timeLas tMod ,  gl. subtype, 

686  gl. openAtCrash) ; 

687 

688  END  MODULE 
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1  $("  MODULE:  fmi. specs  (version  4.14) 

2  CONTENTS:  File  Miscellaneous  Operations 

3  TYPE:  SPECIAL  specifications 

4  LAST  CHANGED:  12/23/80,  16:48:40 

5  ") 

6 

7 

8  MODULE  fmi 

9 

10 

11  $(  this  module  contains  miscellaneous  file  operations  that  are  not  included 

12  in  the  fca  module,  because  the  SPECIAL  checker  at  FACC  cannot  accomodate 

13  the  combined  file) 

14 

15  TYPES 

16 

17  $ ( FROM  stnx) 

18  nonDisType:  STRUCT_OF( 

19  INTEGER  securityLevel ;  SETOF  securityCat  securityCatS ; 

20  INTEGER  IntegrityLevel ;  SET_0F  integrityCat  integrityCatS ) ; 

21  daType:  SETOF  daMode; 

22  modeStruct:  STRUCT_OF( daType  ownerMode,  groupMode,  allMode); 

23  tiiStruct:  STRUCT_OF(nonDisType  nd;  modeStruct  ms;  INTEGER  owner,  group; 

24  SET_0F  privType  priv); 

25 

26  $(from  fca) 

27  globalData:  STRUCT_OF( INTEGER  linkCount,  open Count  ,  timeLastMod; 

28  seid  subtype;  BOOLEAN  openAtCrash) ; 

29  ioStatus:  STRUCT_0F( INTEGER  devlndep,  devDep); 

30  asyncld:  CHAR; 

31  fileBlock:  VECTOROF  CHAR; 

32  openFileEntry :  STRUCT_0F(seid  openSeid;  SET_0F  openModes  openMode); 

33  readResult:  STRUCT_OF(VECTOR_OF  fileBlock  data;  ioStatus  errst); 

34  deviceStruct:  STRUCTOFC BOOLEAN  addressable; 

35  INTEGER  minRequest,  maxRequest,  modSize,  maxBlockNo); 

36  mountTableEntry :  STRUCT_0F(seid  devSeid;  BOOLEAN  readonly; 

37  tiiStruct  devTii;  globalData  devGl); 

38  fileSystemEntry :  STRUCT_0F(seid  fileSeid;  globalData  gl ;  tiiStruct  til; 

39  VECT0R_0F  fileBlock  fileData); 

40  fileSystem:  SET_0F  fileSystemEntry; 

41 

42  fileNsp:  {129  ..  255};  $(  nsp  values  for  file  systems  ) 

43 

44  DEFINITIONS 

45 

46  $(these  definitions  are  explained  in  the  fca  module) 

47 

48  INTEGER  FCAfileSize(seid  fSeid)  IS 

49  CARDINALITY( {INTEGER  i  |  FCAfileData(f Seid,  I)  ?}); 

50 

51  deviceStruct  deviceDataSeld(seid  fSeid)  IS 

52  DDFdeviceData(FCAdeviceType(fSeid)) ; 

53 

54  BOOLEAN  isCurrentPath(seid  tSeid)  IS 

55  EXISTS  terminalGroup  t  :  FCAcurrentPath(t)  -  tSeid; 

56 
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57  BOOLEAN  is ReadOnly(seid  fSeid)  IS 

58  FCAmountTable(SENseidNsp(fSeid)). readonly  -  TRUE; 

59 

60  $(When  a  file's  link  count  goes  to  zero,  its  link  count  becomes  which 

61  means  that  it  does  not  exist  for  any  operation,  including  K_link.  The 

62  file  cannot  be  physically  deleted  until  its  open  count  becomes  zero,  though.) 

63 

64  BOOLEAN  logicalFileExistence (seid  fSeid)  IS 

65  FCAinfo(fSeid)  ?  AND  FCAinfo(f Seid).linkCount  ?; 

66 

67  EXTERNAL REFS 

68 

69  FROM  ddf: 

70 

71  VFUN  DDFdeviceData(deviceType  d)  J>  deviceStruct  ds ; 

72 

73  FROM  smx: 

74  seid:  DESIGNATOR; 

75  secureEntityType:  {tFile,  tDevice,  tTerminal,  tProcess ,  tSegment,  tSubtype, 

76  tExtent ,  tNull}; 

77  privType:  { 

78 

79 

80 
81 
82 

83 

84 

85 

86 

87 

88 

89 

90  securityCat:  DESIGNATOR; 

91  integrityCat:  DESIGNATOR; 

92  daMode:  {daRead,  daUrite,  daExecute}; 

93  VFUN  SENseidNsp(seid  a)  *>  INTEGER  nsp; 

94  VFUN  SENseidType(seid  s)  *>  secureEntityType  set; 

95  VFUN  TIIinfo(seid  s)  *>  tiiStruct  tiist; 

96  VFUN  SMXhasPriv(seid  pSeid;  privType  priv)  •>  BOOLEAN  b; 

97  VFUN  SMXf low(seid  pSeid,  oSeid;  daType  d)  *>  BOOLEAN  b; 

98  VFUN  SMXdap(seid  pSeid,  oSeid;  daType  d)  *>  BOOLEAN  b; 

99 

100  FROM  f ca : 

101  openDescriptor:  DESIGNATOR; 

102  openModes:  {omRead,  omWrite,  omExclusiveRead,  omExcluaive Write} ; 

103  IOfunction:  {rewind,  etc}; 

104  deviceType:  {RK05,  RWP04 ,  RWP05 ,  RWP06,  RSW04,  TWE16,  TM11,  TU56,  PR11, 

105  PC11,  LPli,  IMP11B,  LHDH} ; 

106  terminalGroup:  DESIGNATOR; 

107  seid  FCArootSeid; 

108  VFUN  FCAdeviceType(seid  fSeid)  J>  deviceType  d; 

109  VFUN  FCAcurrentPath (terminalGroup  t)  *>  seid  s; 

110  VFUN  FCAterminalPathSet (terminalGroup  t)  *>  SET_0F  seid  as; 

111  VFUN  FCAmountTable(fileNsp  nsp)  *>  mountTableEntry  mte; 

112  VFUN  FCAextentToFileSys (VECT0R_0F  fileBlock  fb;  fileNsp  nsp) 


privFileUpdateStatus , 

privLockSeg, 

privMount , 

privStickySeg, 

pri vViolSimpSecuri t y , 

privViolSimpIntegrity, 

pri vViolDiscr Access , 

privSignal, 

privHalt, 

privViolCompartments , 
privlmmigrate 
}; 


privLink, 

privModifyPriv, 

privSetLevel, 

privSetPath, 

privViolStarSecurity, 

privViolStarlntegrity, 

p  ri vReali zeExecPe rmiss ion , 

privWalkPTable , 

privKernelCall, 

pri vSetConm, 
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113  *>  fileSystem  fs ; 

114  VFUN  FCAinf o(seld  fSeid)  »>  globalData  gl; 

115  VFUN  FCAf lie Data (seid  fSeid;  INTEGER  blockNo)  *>  fileBlock  fb; 

116  VFUN  FCAinputStream(seid  fSeid)  *>  VECTOR_OF  CHAR  vc ; 

117  VFUN  FCAoutputStream(seid  fSeid)  *>  VECTOR_OF  CHAR  vc; 

118  VFUN  FCAopenTableExists (seld  pSeid)  J>  BOOLEAN  b; 

119  VFUN  FCAopenEntry(seid  pSeid;  openDescrlptor  od)  J>  openFlleEntry  oe ; 

120 
121 

122  FUNCTIONS 

123 

124  $(**»**•»••*»*****»•*•*»**  process  support  operations  ***** *********** 


126  $(Note:  the  function  FCAcreateOpenTable  Is  sufficient  to  support  PROspawn. 

127  The  other  support  operations  are  listed  here.) 


129  OFUN  FMIforkSupport(seid  parent,  child); 


$(FMIforkSupport ) 


$(This  function  creates  a  new  open  table,  "child,"  and  copies  all  open 
from  "parent"  into  It) 

EXCEPTIONS 

XexclusiveFile: 

EXISTS  openDescrlptor  od 

:  {omExclusiveRead , omExclusiveWrlte}  SUBSET 
FCAopenEntry (parent,  od ).openMode; 

ASSERTIONS 

FCAopenTableExis ts (parent ) ; 

NOT  FCAopenTableExists (child ) ; 

EFFECTS 

'FCAopenTableExists (child )  =  TRUE; 

FORALL  openDescrlptor  od; 

openFlleEntry  oe  *  FCAopenEntry(parent ,  od); 
globalData  gl  *  FCAinf o(oe.openSeid) 

:  'FCAopenEntry( child,  od)  ■  oe 
AND  'FCAinfo(oe.openSeld) 

-  STRUCT (gl. linkCount ,  gl.openCount  +  1,  gl. tlmeLastMod , 
gl. subtype,  gl .openAtCrash) ; 


151  OFUN  FMIreleaseSupport(seid  pSeid); 


$(FCArelea8eSupport) 


$(  Closes  all  the  open  objects  of  an  open  object  table  and  deletes  the 
table) 

DEFINITIONS 

INTEGER  n0pen(oper Descriptor  od) 

IS  CARDINALITY( {openDescrlptor  odl 

|  FCAopenEntry(pSeld,  od).openSeid 

-  FCAopenEntry(pSeid,  odl) .openSeld} ) ; 

$(the  number  of  times  an  object  corresponding  to  a 
given  open  descriptor  Is  opened  by  this  process) 
seid  s(openDescrlptor  od)  IS  FCAopenEntry (pSeid,  od). openSeld; 
ASSERTIONS 

FCAopenTableExists (pSeid) ; 

EFFECTS 

FORALL  openDescrlptor  od  |  FCAopenEntry (pSeid,  od)  ?; 
globalData  gl  *  FCAinf o(s (od)) 

:  'FCAopenEntry(pSeid,  od)  -  ? 

AND  ( IF(  gl. linkCount  -  0  OR  gl. linkCount  -?) 
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169  AND  gl.open 

170  AND  SENseid 

171  THEN  'FC 

172  AND  'T 

173  AND  (F 

174  ELSE 

175  'FCAin 

176  -  ST 

177 

178 

179 

180  'FCAopenTableExists (pSeid ) 

181 

182  $(inuiinniiiniuiiiii  1 

183 

184  OFUN  FCAlink(seid  pSeid,  f); 

185  $ (Increments  the  link  coun 


AND  gl.openCount  -  nOpen(od) 

AND  SENseidType(s(od))  -  tFile 
THEN  'FCAinfoCs(od))  -  ? 

AND  'TIIlnfo(s(od))  -  ? 

AND  (FORALL  INTEGER  i  :  'FCAf ileData(s (od ),  i)  -  ?) 
ELSE 

'FCAinfo(s (od)) 

-  STRUCT (gl.linkCount, 

gl.openCount  *  nOpen(od), 
gl. timeLastMod,  gl. subtype, 
gl . openAtCrash ) ) ; 

Exists (pSeid )  »  FALSE; 


link  and  unlink  operations 


UN  FCAlink(seid  pSeid,  f);  $(FCAlink) 

$ (increments  the  link  count  of  an  existing  file.  Mandatory  access  is 
required,  and  the  process  must  have  the  privilege  to  link.  The  file 
system  must  not  be  mounted  in  read  only  mode) 

DEFINITIONS 

globalData  fs  IS  FCAinfo(f); 

EXCEPTIONS 

XbadPriv:  NOT  SMXhasPriv(pSeid,  privLink); 

XnoFile:  NOT(logicalFileExis tence(f )  AND  SMXf low(pSeid,  f,  {daWrite})); 
XnoFile:  SENseidType(f )  “*  tFile;  $(  not  a  file,  but  exists  ) 
XnotWritable:  isReadOnly(f ); 

ASSERTIONS 

FCAopenTableExis  ts (pSeid ) ; 

EFFECTS 

'FCAinfo(f) 

■  STRUCT(fs.linkCount  +  1,  fs . openCount ,  fs. timeLastMod, 
fs. subtype,  fs. openAtCrash) ; 


202  OFUN  FCAunl ink (s e id  pSeid,  f); 


$(FCAunlink) 


$ (decrements  the  reference  count  of  an  existing  file.  Mandatory  access  is 
required  and  the  process  must  have  the  privilege  to  link.  The  file 
system  that  the  file  is  on  must  not  be  mounted  in  read  only  mode.  Note 
that  unlinking  can  cause  the  file  to  be  deleted  if  the  link  count  goes 
to  zero  and  the  file  is  not  open  anywhere) 

DEFINITIONS 

globalData  fs  IS  FCAinfo(f); 

EXCEPTIONS 

XbadPriv:  NOT  SMXhasPri v(pSeid ,  privLink); 

XnoFile:  NOT(logicalFileExistence (f )  AND  SMXf iow(pSeid,  f,  {daWrite})); 

XnoFile:  SENseidType(f )  ~m  tFile; 

XnotWritable:  isReadOnly(f ) ; 

ASSERTIONS 

FCAopenTableExis  ts (pSeid ) ; 

EFFECTS 

IF  ((fs .linkCount  <■  1)  OR  (fs.linkCount  ■  ?)) 

AND  f s . openCount  ■  0 


THEN  'FCAinfo(f)  -  ? 

AND  (FORALL  INTEGER  i 
AND  'TIIinfo(f)  -  ? 
ELSE  'FCAinfo(f)  - 


$(if  true,  then  delete  file) 
'FCAfileData(f ,  i)  -  ?) 
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225 

226 

227 

228 

229 

230 

231 

232 

233 

234 

235 

236 

237 

238 

239 

240 

241 

242 

243 

244 

245 

246 

247 

248 

249 

250 

251 

252 

253 

254 

255 

256 

257 

258 

259 

260 
261 
262 

263 

264 

265 

266 

267 

268 

269 

270 

271 

272 

273 

274 

275 

276 

277 

278 

279 

280 


$(' 


STRUCT ((IF  fs . linkCount  <«  1  THEN  ?  ELSE  fs.linkCount  *  1), 
fs .openCount ,  fs . timeLastMod,  fs. subtype,  fs. openAtCrash) ; 

111111111111111  basic  I/O  operations  uminimiiiiimiiiiiin) 


VFUN  FCAvReadBlocks(seid  pSeid;  openDescriptor  od;  INTEGER  blockNo,  size; 

asyncld  id)  $(FCAvReadBlocks ) 

*>  readResult  rr; 

$(the  purpose  of  this  function  is  to  return  the  result  that  FCAreadBlocks 
would  return  if  executed) 

$(returns  blocks  that  are  read  from  a  given  file,  device,  extent,  or 
terminal,  the  object  must  be  open  for  reading,  the  block  number  and 
size  must  be  within  range  for  the  kind  of  object  specified,  note 
that  files,  extents,  and  addressable  devices  are  handled  differently 
from  terminals  and  nonaddressable  devices,  with  respect  to  the  data.) 
DEFINITIONS 

seid  fSeid  IS  FCAopenEntry(pSeid ,  od).openSeld; 
deviceStruct  d 

IS  IF  SENseidType (fSeid)  -  tDevice  THEN  deviceDataSeid(f Seid ) 

ELSE  IF  SENseidType (fSeid)  INSET  {tFile,  tExtent) 

THEN  STRUCT (TRUE,  512,  32768,  512,  FCAfileSize(fSeid)Jl) 

ELSE  STRUCT (FALSE ,  1,  255,  1,  0);  S(tTerminal) 

INTEGER  blockCount  IS  size/512; 

INTEGER  blockPast  IS  (IF  SENseidType (fSeid)  -  tDevice  THEN 

MIN( (d . maxBlockNo ,  blockNo+blockCount } ) 

ELSE 

MIN( {FCAfi leSize(f Seid ) , blockNo+blockCount } ) ) ; 

EXCEPTIONS 

XbadOd :  FCAopenEntry(pSeid ,  od)  =  ?; 

XbadSize:  size  «  0; 

XnotReadable:  NOT  oraRead  INSET  FCAopenEntry(pSeid,  od).openMode; 

$(  EXCEPTIONS  AFTER  THIS  POINT  ARE  ACTUALLY  HANDLED  AS  I/O  ERRORS; 

In  addition,  the  following  exceptions  may  not  be  treated  as  "pure" 
in  the  implementation,  i.e.,  they  may  involve  effects  in  the  code.) 
XbadBlockNo: 

NOT  size  INSET  {d.minRequest 
OR  (size  MOD  d.modSize)  0; 

XbadBlockNo:  NOT  blockNo  INSET  {0 
XendOfFile: 

d. addressable  AND  blockNo  +  size/d. modSize  >  d. maxBlockNo ; 

Xerror:  RES0URCE_ERR0R; 

ASSERTIONS 

FCAopenTableExists (pSeid ) ; 

DERIVATION 

IF  d. addressable  THEN 
STRUCK 

VECT0R(F0R  i  FROM  blockNo  TO  blockPast  *.'l 
:  FCAfileData (fSeid,  i)), 

SOME  ioStatus  ios  |  TRUE) 

ELSE 

LET  INTEGER  si  INSET  {0  ..  size/d. modSize} 

$(Must  let  si  be  nondeterministically  selected  for  nonaddress,  dev) 
IN  STRUCK 

VECTOR (FOR  i  FROM  1  TO  si  $( d.modSize  -  1) 

:  VECTOR ( FCAinput  S  t  r ea m ( f  S e i d ) [ i ] ) ) , 

SOME  ioStatus  ios  |  TRUE); 


d.maxRequest } 

d. maxBlockNo} ; 
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282  OVFUN  FCAreadBlocks(seid  pSeid;  openDes crip tor  od;  INTEGER  blockNo,  size; 


283 

284 

285 

286 

287 

288 

289 

290 

291 

292 

293 

294 

295 

296 

297 

298 

299 

300 

301 

302 

303 

304 

305 

306 

307 

308 

309 

310 

311 

312 

313 

314 

315 

316 

317 

318 

319 

320 

321 

322 

323 

324 

325 

326 

327 

328 

329 
3j0 

331 

332 

333 

334 

335 

336 


$ (FCAreadBlocks ) 


asyncld  id) 

*>  readResult  rr; 

$(LR  11  needs  semantics  for  asynchronous  I/O) 

$(retums  blocks  that  are  read  from  a  given  file,  device,  extent,  or 
terminal,  the  object  must  be  open  for  reading,  the  block  number  and 
size  must  be  within  range  for  the  kind  of  object  specified,  note 
that  files,  extents,  and  addressable  devices  are  handled  differently 
from  terminals  and  nonaddress able  devices,  with  respect  to  the  data.) 
DEFINITIONS 

seid  fSeid  IS  FCAopenEntry(pSeid,  od).openSeid; 
deviceStruct  d 

IS  IF  SENseidType(fSeid)  ■  tDevice  THEN  deviceDataSeid (fSeid) 

ELSE  IF  SENseidType(fSeid)  INSET  {tFile,  tExtent} 

THEN  STRUCT (TRUE,  512,  32768,  512,  FCAf ileSize(f Seid)M ) 

ELSE  STRUCT( FALSE ,  1,  255,  1,  0);  $(tTerminal) 
readResult  rrl  IS  FCAvReadBlocks (pSeid,  od,  blockNo,  size,  id); 

EXCEPTIONS 

EXCEPTIONS  OF  FCAvReadBlocks (pSeid,  od,  blockNo,  size,  id); 

ASSERTIONS 

FCAopenTableExis ts (pSeid); 

EFFECTS 
rr  -  rrl; 

NOT  d. addressable 

->  'FCAinputStream(fSeid) 

»  VECTOR (FOR  i  FROM  LENGTH (rrl. data)  +  1 

TO  LENGTH(FCAinputStream(f Seid)) 

:  FCAinputStream(fSeid)[i] ); 

OVFUN  FCAwriteBlocks(seid  pSeid;  openDes cript or  od;  INTEGER  blockNo; 

VECTOR_0F  f ileBlock  vfb;  asyncld  id) 

*>  ioStatus  ios;  $(FCAwriteBlocks ) 

$(LR  J*  needs  asynchronous  1/0) 

$(writes  the  contents  of  a  vector  of  file  blocks  onto  the  object  mentioned. 

the  data  must  correspond  to  the  parameters  of  the  openable  object.) 
DEFINITIONS 

seid  fSeid  IS  FCAopenEntry( pSeid,  od).openSeid; 
secureEntityType  type  IS  SENseidType(fSeid); 
deviceStruct  d 

IS  IF  type  »  tDevice  THEN  deviceDataSeid (fSeid) 

ELSE  IF  type  INSET  {tFile,  tExtent} 

THEN  STRUCT (TRUE,  512,  32768,  512,  FCAfileSize(fSeid)) 

ELSE  STRUCT (FALSE ,  1,  255,  1,  0); 

INTEGER  size  IS  LENGTH(vfb) ; 

INTEGER  blockCount  IS  size/512; 

INTEGER  blockPast  IS  (IF  SENseidType(f Seid )  -  tDevice  THEN 

MIN({d.maxBlockNo,  blockNo+blockCount }) 

ELSE 

blockNo+blockCount ) ; 

EXCEPTIONS 

XbadOd:  NOT  (FCAopenEntry(pSeid,  od)  ?); 

XbadSize:  LENGTH(vfb)  -  0; 

XnotWritable:  NOT  omWrite  INSET  FCAopenEntry(pSeid,  od ) . openMode ; 

XnoSpace :  RES0URCE_ERR0R ; 
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337  $( 
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370  $( 

371 


EXCEPTIONS  AFTER  THIS  POINT  ARE  ACTUALLY  HANDLED  AS  I/O  ERRORS 

In  addition,  the  following  exceptions  may  not  be  treated  as  "pure" 
in  the  implementation,  l.e.,  they  may  involve  effects  in  the  code.) 
XbadSize: 

NOT  LENGTH(vfb)  INSET  {d.minRequest  ..  d.maxReques t } 

OR  (LENGTH(vfb)  MOD  d.modSize)  “«  0; 

XbadBlockNo:  NOT  {blockNo  ..blockNo  +  LENGTH (vfb)  *1}  SUBSET 
{0  ..  d.maxBlockNo) ; 

XendOfFile:  d. addressable  AND  type  “«  tFile 
AND  blockNo  +  LENGTH(vfh)  >  d.maxBlockNo; 

XnoSpace :  RES0URCE_ERR0R ; 

ASSERTIONS 

F0RALL  INTEGER  i |vfb[i]~-?;  INTEGER  j  |  vfb[j]~«?  : 

LENGTH(vfb[ij)  =  LENGTH(vfb[ jj) ; 

EFFECTS 

ios  *  (SOME  ioStatus  iosl  |  TRUE); 

IF  d. addressable 

THEN  F0RALL  INTEGER  i 

:  'FCAf ileData(f Seid,  i) 

=  (IF  NOT  i  INSET  {blockNo  ..  blockPast  ‘  1} 

THEN  FCAf i leData(f Seid,  i) 

ELSE  vfb [ 1  J  blockNo  +1]) 

ELSE  ' FCAoutput Stream (f Seid) 

-  VECT0R(F0R  i  FROM  1 

TO  LENGTH(FCAoutputStream(f Seid) )+LENGTH( vfb) 
:  IF  i  <■  LENGTH(FCAoutputStream(f Seid)) 

THEN  FCAoutputStream( f Seid ) [ i ] 

ELSE 

vf  b  [  (  i  *  LENGTH  (  FCAou  t pu  t  S  t  r earn  (f  Se id  )  )  )  /LENGTH  (  vf  b  )  ] 
[ ( i* LENGTH (FCAoutput St ream(f Seid )) )MOD  LENGTH(vfb)] ) ; 


general  device  manipulation 


) 


372  VFUN  FCAvDeviceFunction(seid  pSeld;  openDescriptor  od;  IOfunction  f; 

373  VECT0R_0F  INTEGER  args;  asyncld  id) 

374  *>  IoStatus  status;  $(FCAvDe vice Function) 

375  $(the  purpose  of  this  function  is  to  return  the  value  that  FCAdeviceFunction 

376  would  return  if  it  were  executed  in  a  given  state) 

377  $(the  specification  of  this  function  is  device dependent ,  but  may  be 

378  filled  in  at  a  later  time) 

379  DEFINITIONS 

380  seid  dSeld  IS  FCAopenEntry(pSeld,  od).openSeld; 

381  EXCEPTIONS 

382  XnoFlle:  FCAopenEntry(pSeid,  od)  ■  ?; 

383  XbadDevice :  NOT  SENseidType(dSeld)  INSET  {tDevice,  tTerminal}; 

384  $(  there  should  be  an  exception  here  which  uses  a  table  of  functions 

385  vs  read/write  permissions  required  to  return  XnotReadable  or 

386  XnotWrltable  as  required.  JN  ) 

387  ASSERTIONS 

388  FCAopenTableExists(pSeid); 

389  DERIVATION 

390  SOME  ioStatus  ios  |  TRUE; 

391 

392  0VFUN  FCAdeviceFunction(seid  pSeid;  openDescriptor  od;  IOfunction  f; 
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393  VECTORjOF  INTEGER  args ;  aayncld  id) 

394  *>  ioStatus  status;  $(FCAdeviceFunction ) 

395  $(the  specification  of  this  function  is  device 'dependent ,  but  may  be 

396  filled  in  at  a  later  time) 

397  EXCEPTIONS 

398  EXCEPTION S_OF  FCAvDeviceFunction(pSeid,  od,  f,  args,  id); 

399  ASSERTIONS 

400  FCAopenTableExists(pSeld); 

401  EFFECTS 

402  $(the  state  of  the  device  somehow  changes,  and  the  result  is  returned  via 

403  the  lo  status) 

404  status  *  FCAvDeviceFunction(pSeid,  od,  f,  args,  id); 

405  TRUE ; 

406 

407  0FUN  FCAterminalLock(seid  pSeld,  devSeld);  $(FCAterminalLock) 

408  $(sets  the  current  terminal  in  the  group  to  be  "devSeld".  The  requesting 

409  process  must  have  the  privilege  to  lock  terminals) 

410  $(  Actually,  this  functionality  is  now  performed  by  the 

411  function  SETPATH  through  K_device  function.  JN) 

412  EXCEPTIONS 

413  XnoPriv:  NOT  SMXhasPriv(pSeid,  privSetPath); 

414  XnoClass :  SENseidType(devSeid)  tTerminal; 

415  XnoFile:  FCAinf o(devSeld)  ■  ?; 

416  ASSERTIONS 

417  FCAopenTableExists(pSeid); 

418  EFFECTS 

419  LET  termlnalGroup  t  |  devSeld  INSET  FCAtermlnalPathSet(t) 

420  IN  'FCAcurrentPath(t)  ■  devSeld; 

421 

422  mounting  and  unmounting  operations  ***»**»*****«***«•") 

423 

424  OVFUN  FCAmount (seid  pSeid,  dev;  BOOLEAN  readonly)  $(FCAmount) 

425  J>  fileNsp  newNsp; 

426  $(performs  the  logical  mounting  of  a  file  system  from  an  extent.  The 

427  semantics  are  described  in  the  general  commentary  in  the  FCA 

428  specification) 

429  DEFINITIONS 

430  fileNsp  openSlot  IS 

431  SOME  fileNsp  freeMountNsp  |  FCAmountTable(freeMountNsp)  *  ?; 

432  fileSystem  fileSys  IS 

433  FCAextentToFileSys (VECT0R(F0R  i  FROM  1  TO  FCAf ileSlze(dev) 

434  :  FCAfileData(dev,  i)),  openSlot)  ; 

435  $(the  file  system  produced  by  the  data  on  the  extent) 

436  fileSystemEntry  fse(seid  f)  IS 

437  SOME  fileSystemEntry  fsel  |  feel  INSET  fileSys  AND  fsel.flleSeid  -  f; 

438  $(the  entry  in  the  file  system  with  a  given  seid) 

439  EXCEPTIONS 

440  XbadPriv:  NOT  SMXhasPriv(pSeld,  privMount); 

441  XnoFile:  NOT  (FCAinf o (dev)  7); 

442  XnoClass:  SENseidType(dev)  ”•  tExtent; 

443  XmntSpace:  RES0URCE_ERR0R ; 

444  ASSERTIONS 

445  FCAopenTableExists(pSeld); 

446  EFFECTS 

447  newNsp  *  openSlot;  $(  return  new  mount  slot  ) 

448  'FCAmountTable(openSlot) 
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449  *  STRUCT(dev,  readonly,  Tllinfo(dev),  FCAinfo(dev)) ; 

450  'FCAinf o(dev)  -  ?; 

451  FORALL  INTEGER  i  :  'FCAf ileData(dev,  i)  -  ?; 

452  'TI Iinf o(dev)  -  ?; 

453  FORALL  seid  f  |  fse(f)  ? 

454  :  ' FCAinf o(f)  -  fse(f).gl 

455  AND  (FORALL  INTEGER  i  INSET  {1  ..  LENGTH(fse(f ). fileDaca)} 

456  :  'FCAfileData(f ,  1*1)-  fse(f ). fileData [i ] ) 

457  AND  'TIIinfo(f)  -  fse(f).tii; 

458 

459  OFUN  FCAunmount (seid  pSeld;  fileNsp  fsNsp);  $(FCAunmount ) 

460  $(performs  logical  unmounting  of  a  file  system.  Restores  the  extent 

461  so  that  it  can  be  accessed) 

462  DEFINITIONS 

463  mountTableEntry  mte  IS  FCAmountTable (fsNsp ) ; 

464  fileSystem  fs  IS 

465  {fileSystemEntry  fse 

4*6  |  LET  seid  fSeid  |  SENseidNsp (f Seid )  -  fsNsp  AND  FCAinf o(f Seid)  ? 

467  IN  fse  -  STRUCT(f Seid,  FCAinf o(f Seid ) ,  Tllinfo(fSeid), 

468  VECT0R(F0R  i  FROM  1  TO  FCAf ileSize(f Seid ) 

469  :  FCAf i leData (fSeid,  i  *  1)))}; 

470  $(  the  state  of  the  file  system  to  be  unmounted) 

471  VECT0R_0F  fileBlock  extData 

472  IS  SOME  VECTO R_OF  fileBlock  vfb 

473  |  FCAextentToFileSys (vfb, fsNsp)  -  fs; 

474  $(given  the  state  of  the  file  system,  the  extent  that  is  equivalent  to 

475  it) 

476  seid  dev  IS  FCAmountTable (fsNsp). devSeid;  $(  underlying  device  ) 

477  EXCEPTIONS 

478  XbadPriv:  NOT  SMXhasPriv(pSeid,  privMount); 

479  XnoXXX:  FCAmountTable (fsNsp )  »  ?; 

480  XnoTranquil: 

481  EXISTS  seid  fSeid  I  SENseidNsp(fSeid)  -  fsNsp 

482  :  FCAinf o(f Seid). openCount  >  0; 

483  ASSERTIONS 

484  FCAopenTableExists(pSeid); 

485  EFFECTS 

486  "FCAinf o(dev)  -  mte.devGl; 

487  'TIIinfo(dev)  -  mte.devTii; 

488  FORALL  INTEGER  i  INSET  {1  ..  LENGTH(extData) } 

489  :  'FCAf ileData (dev,  i  *  1)  -  extData[iJ; 

490  $(the  device's  state  "comes  back") 

491  FORALL  seid  fSeid  I  SENseidNsp(f Seid )  -  fsNsp 

492  :  'TIIinfo(fSeid)  -  ? 

493  AND  'FCAinf o (fSeid)  -  ? 

494  AND  (FORALL  INTEGER  i  :  'FCAf ileData(f Seid,  i)  »  ?); 

495  $(the  state  of  all  files  on  the  file  system  "disappears") 

496  FCAmountTable (fsNsp)  -  ?; 

497 

498 

499  END  MODULE 
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1  $(" 

2 

3 

4 

5  ") 

6 
7 


MODULE: 

CONTENTS: 

TYPE: 

LAST  CHANGED: 


lev. specs  (version  4.9) 
System  Levels 
SPECIAL  specifications 
7/28/80,  09:51:43 


8  MODULE  lev 


9 

10 

11  $(  This  module  enables  the  centralization  of  the  get  and  set  level  operations 

12  for  all  modules.  Each  module  maintains  the  type*independent  operation 

13  of  its  own  objects,  and  applies  certain  conditions  to  the  getting  and 

14  setting  of  this  information.  However,  there  is  only  one  kernel  operation 

15  for  getting  levels,  and  one  for  setting  levels,  of  all  objects.  The 

16  operations  are  combined  in  this  module) 

17 

18  TYPES 

19 

20  $(from  smx) 

21  nonDisType:  STRUCT_OF( 

22  INTEGER  securityLevel;  SET_0F  securityCat  securityCatS ; 

23  INTEGER  integrityLevel ;  SET_0F  integrityCat  integrityCatS) ; 

24  daType :  SET_OF  daMode ; 

25  modeStruct:  STRUCT_0F( daType  ownerMode,  groupMode,  allMode); 

26  tiiStruct:  STRUCT_0F( nonDisType  nd ;  modeStruct  ms;  INTEGER  owner,  group; 

27  SETjOF  privType  priv); 

28 

29  $ (FROM  pvm) 

30  globalData : 


31  STRUCT_0F( BOOLEAN  sharable,  swappable,  sticky,  memAdvise,  executable; 

32  direction  growth); 

33  instanceScruct : 

34  STRUCTjOF (globalData  gl;  direction  growth;  INTEGER  refCount;  VECTOR_OF  INTEGER  data); 

35 

36  $ (FROM  fca) 

37  openFileEntry :  STRUCT  0F(seid  openSeid;  SET_0F  openModes  openMode); 


38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 


EXTERN ALREFS 

FROM  smx: 
seid:  DESIGNATOR; 
secureEntityType :  {tFile, 
tExtent 
securityCat:  DESIGNATOR; 
integrityCat:  DESIGNATOR; 
daMode:  {daRead,  daWrlte,  daExecute}; 
privType:  { 


tDevice,  tTerminal,  tProcess ,  tSegment,  tSubtype, 
,  tNull} ; 


privFileUpdateStatus , 
privLockSeg, 
privMount , 
prlvStickySeg, 
privViolSiopSecurity, 
privViolSimpIntegri ty, 
prlvViolDiscrAccess , 


privLink, 

privModifyPriv, 

prlvSetLevel, 

privSetPath, 

privViolStarSecurity, 

privViolS tar Integrity, 

privRealizeExecPermission, 
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57  privSignal,  privWalkPTable , 

58  privHalt,  privKernelCall, 

59  privViolCoapartments ,  p'ivSetCoam, 

60  privlmmigrate 

61  }; 

62 

63  VFUN  SENseidType(seid  s)  *>  secureEntityType  set; 

64  VFUN  TIIgetEntityLevel (seld  pSeld,  oSeid)  J>  tiiStruct  ntll; 

65  OFUN  TIIsetEntityLevel(seid  pSeld,  oSeid;  tiiStruct  ntil); 

66 

67  FROM  pvm: 

68  direction:  {up,  down}; 

69  VFUN  SEGinstanceInfo(seid  s)  *>  instanceStruct  is; 

70 

71  FROM  fca: 

72  openDescriptor :  DESIGNATOR; 

73  openModes :  {omRead,  omWrite,  omExclus iveRead ,  omExclusiveWrite } ; 

74  VFUN  FCAopenEntry(seid  pSeid;  openDescriptor  od)  J>  openFileEntry  oe; 

75 

76 

77  FUNCTIONS 

78 

79  VFUN  LEVgetObjectLevel(seid  pSeid,  oSeid)  *>  tiiStruct  otii; 

80  EXCEPTIONS 

81  EXCEPTIONS_0F  TIIgetEntityLevel (pSeid,  oSeid); 

82  DERIVATION 

83  TIIgetEntityLevel(pSeid,  oSeid); 

84 

85  OFUN  LEVsetOb jectLevel (seid  pSeid,  oSeid;  tiiStruct  otii); 


87  DEFINITIONS 


$ (LEVsetOb jec  tLevel ) 


88  secure! 

89  EXCEPTI0I 

90  EXCEPT 

91  XnoObj 

92 

93  OR  (typ 

94  AN! 

95 

96  EFFECTS 

97  EFFECT 

98 

99 

100  END  MODULE 


secureEntityType  type  IS  SENseidType(oSeid); 

EXCEPTIONS 

EXCEPTI0NS_0F  TIIsetEntityLevel(pSeid,  oSeid,  otii); 

XnoObj  : (type  ■  tSegaent 

AND  SEGinstanceInfo(oSeid).gl.sharable  «  TRUE) 
OR  (type  INSET  {tFlle,  tDevice,  tSubtype,  tTerminal,  tExtent) 
AND  (EXISTS  seid  pSeldl;  openDescriptor  od  : 

FCAopenEntry(pSeidl ,  od).openSeid  ■  oSeid)); 

EFFECTS 

EFFECTS_0F  TIIsetEntityLevel (pSeid,  oSeid,  oti$); 
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1  $(”  MODULE: 

2  CONTENTS: 

3  TYPE: 

4  LAST  CHANGED: 

5  ") 

6 

7 

8  MODULE  mac 

9 

10  PARAMETERS 

11 


mac. specs  (version  4.5) 
Machine 

SPECIAL. specif ications 
7/28/80,  09:52:15 


12  INTEGER  MACmaxVAddr,  $(  maximum  virtual  address,  also  maximum  segment  size 

13  2' 16  *  1  on  PDP* 11/70) 

14  MACmaxOf fset ,  $(  maximum  offset  component  of  virtual  address, 

15  2*13  *  1  on  PDP*ll/70) 

16  MACmaxReg;  $(  maximum  memory  mapping  register  address,  seven  on 

17  PDP'11/70) 

18 

19  FUNCTIONS 

20 

21  VFUN  MACclockO  *>  INTEGER  time; 

22  $(  integer  that  represents  real  time) 

23  INITIALLY  TRUE; 

24 

25  OFUN  MACclocklncrement ( ) ; 

26  $(  invlked  continuously  by  a  separate  abstract  process  14  the  system  clock) 

27  EFFECTS 

28  'MACclockO  =  MACclockO  +  1; 

29 

30 

31  END  MODULE 


Version  4.4 


-101- 


VDL-TR7932 


pbl. specs  Page  1  Wed  Mar  18  11:12:29  1981 

1  $("  MODULE:  pbl. specs  (version  4.7) 

2  CONTENTS:  Parameter  Block  Functions 

3  TYPE:  SPECIAL  specifications 

4  LAST  CHANGED:  12/23/80,  17:17:46 

5  "> 

6 

7 

8  MODULE  pbl 

9 

10  $(  This  module  specifies  the  action  of  getting  arguments  or  putting  results 

11  of  operations  Into  the  virtual  memory  of  a  process.  The  part  of 

12  vlrcual  memory  so  manipulated  is  called  a  parameter  block.  The  need 

13  for  parameter  blocks  comes  about  when  the  length  of  the  data  is  not 

14  constant  for  all  Invocations  of  a  given  operation. 

15 

16  To  make  specifications  more  readable,  all  parameter  block  operations  are 

17  specified  in  two  parts.  The  basic  functionality  of  an  operation  is 

18  specified  in  the  module  to  whose  object  the  operation  refers,  e.g., 

19  the  basic  specification  of  readBlock  comes  from  the  fmi  module.  The 

20  parameter  block  manipulation,  along  with  appropriate  data  conversion, 

21  is  specified  here.  This  decomposition  removes  the  issue  of  parameter 

22  blocks  from  the  basic  specification  of  already  complicated  operations. 

23  The  parameter  block  manipulation  becomes  simple  once  isolated  here.) 

24 

25 

26  TYPES 

27 

28  $(from  mac) 

29  vAddrType:  {0  ..  MACmaxVAddr } ; 

30 

31  $(from  pvm) 

32  virtualLocation: 

33  STRUCT_OF(domainType  domain;  spaceType  idSpace ;  vAddrType  vAddr); 

34  pBlock:  STRUCT_OF(virtualLocation  vloc;  INTEGER  size); 

35 

36  $(from  fca) 

37  asyncld:  CHAR; 

38  f ileStatus :  STRUCT0FC INTEGER  nBlocks,  linkCount ,  timeLastMod;  seid  subtype; 

39  BOOLEAN  openAtCrash ) ; 

40  ioStatus:  STRUCT_0F( INTEGER  devDep); 

41  fileBlock:  VECT0R_0F  CHAR; 

42  readResult:  STRUCT_0F(VECT0R_0F  fileBlock  data;  IoStatus  errst); 

43 

44  $(from  spf) 

45  SPFarga:  VECT0R_0F  INTEGER; 

46 

47 

48  EXTERNALREFS 

49 

50  FROM  mac : 

51  INTEGER  MACmaxVAddr; 

52 

53  FROM  smx: 

54  seid:  DESIGNATOR; 

55  domainType:  {nullDomain,  kernelDomain.supervisorDomain.userDomain} ; 

56 
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FROM  pvm: 

spaceType:  {nullSpace , ISpace ,  dSpace}; 

OFUN  PVMstore(seid  pSeid;  pBlock  block;  VECTOR_OF  INTEGER  vec); 

VFUN  PVMretrleve(seld  pSeid;  pBlock  block)  J>  VECTOR_OF  INTEGER  vec; 

FROM  fca: 

openDescriptor:  DESIGNATOR; 

IOfunction:  {rewind,  etc}; 

FROM  fmi: 

VFUN  FCAvDeviceFunction(seid  pSeid;  openDescriptor  od;  IOfunction  f; 

VECTOR_OF  INTEGER  args ;  asyncld  id) 

*>  ioStatus  status; 

OVFUN  FCAdeviceFunction(seid  pSeid;  openDescriptor  od;  IOfunction  f; 

VECTOR_OF  INTEGER  args;  asyncld  id) 

*>  ioStatus  status; 

VFUN  FCAvReadBlocks (seid  pSeid;  openDescriptor  od;  INTEGER  blockNo,  size; 
asyncld  as)  *>  readResult  rr; 

OVFUN  FCAreadBlocks (seid  pSeid;  openDescriptor  od;  INTEGER  blockNo,  size; 
asyncld  as)  *>  readResult  rr; 

OVFUN  FCAwriteBlocks (seid  pSeid;  openDescriptor  od;  INTEGER  blockNo; 

VECTOR_OF  fileBlock  vfb;  asyncld  id)  *>  ioStatus  ios; 


FROM  spf : 

SPFfunctionType :  {syncSPF,  immSegSPF,  sysHaltSPF,  levelSetSPF} ; 

OFUN  SPFspecialFunction(seid  pSeid;  SPFfunctionType  fn;  SPFargs  args); 


ASSERTIONS 

FORALL  VECTOROF  fileBlock  vfb 

:  PBLwordsToBlocks (PBLblocksToWords(vfb))  ■  vfb; 


FUNCTIONS 


data  conversion  functions  ••iiiiiiiiiimmiiii) 

VFUN  PBLioStatToVec (ioStatus  ios)  »>  VECTOR_OF  INTEGER  vi; 

HIDDEN; 

INITIALLY  vi  “«  ?; 

VFUN  PBLblocksToWords (VECTOR_OF  fileBlock  vfb)  •>  VECTOR_OF  INTEGER  vi ; 
HIDDEN; 

INITIALLY  vi  ”«  ?; 


VFUN  PBLwordsToBlocks (VECT0R_0F  INTEGER  vi)  J>  VECTOR_OF  fileBlock  vfb; 
HIDDEN; 

DERIVATION  SOME  VECTOR_OF  fileBlock  vfbl  |  PBLblocksToWords (vfbl )  -  vi; 

operations  »*»*"‘*»«niniiiiiiiiiiniini) 


OFUN  PBLdeviceFunct ion (seid  pSeid;  openDescriptor  od;  IOfunction  f; 

pBlock  arguments,  status;  asyncld  id); 

$ (PBLdeviceFunction) 


DEFINITIONS 


l 


i 


i 


[ 
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113  VECTOR_OF  INTEGER  inargs  IS  PVMretrteve(pSeid,  arguments); 

114  ioStatus  st  IS  FCAvDeviceFunction(pSeid,  od,  f,  inargs,  id); 

115  VECTOR_OF  INTEGER  result  IS  PBLioStatToVec(s t)  ; 

116  EXCEPTIONS 

117  EXCEPTIONS_OF  PVMretrieve(pSeid,  arguments); 

118  EXCEPTIONS_OF  FCAdeviceFunction(pSeid,  od ,  f,  inargs,  id); 

119  EXCEPTIONS_OF  PVMstore(pSeid,  status,  result); 

120  EFFECTS 

121  EFFECTS_0F  PVMstore(pSeid,  status,  result); 

122  st  »  EFFECTS_0F  FCAdeviceFunction(pSeid,  od,  f,  inargs,  id); 

123 

124  OVFUN  PBLreadBlock(seid  pSeid;  openDescriptor  od;  INTEGER  blockNo; 

125  pBlock  duFile;  asyncld  as) 

126  *>  STRUCT_0F( INTEGER  bytesRead;  ioStatus  errst)  result;  $ (PBLreadBlock) 

127  DEFINITIONS 

128  readResult  rr  IS  FCAvReadBlocks (pSeid,  od,  blockNo,  duFile. size,  as); 

129  VECT0R_0F  INTEGER  intData  IS  PBLblocksToWords ( rr .data) ; 

130  EXCEPTIONS 

131  EXCEPTIONS_OF  FCAreadBlocks (pSeid ,  od ,  blockNo,  duFile. size,  as); 

132  EXCEPTI0NS_0F  PVMstore(pSeid ,  duFile,  intData); 

133  EFFECTS 

134  result  ■  STRUCT ( LENGTH ( intData ) ,  rr.errst); 

135  EFFECTS_0F  PVMstore (pSeid,  duFile,  intData); 

136 

137  OFUN  PBLspecialFunction(seid  pSeid;  SPFfunctionType  fn;  pBlock  parm); 

138  S(PBLspecialFunction) 

139  DEFINITIONS 

140  SPFargs  args  IS  PVMretrieve(pSeid,  parm); 

141  EXCEPTIONS 

142  EXCE PTION S_0 F  PVMretrieve (pSeid,  parm); 

143  EXCEPTIONSOF  SPFspecialFunction(pSeid,  fn,  args); 

144  EFFECTS 

145  EFFECTS_0F  SPFspecialFunction(pSeid,  fn,  args); 

146 

147  OVFUN  PBLwri teBlock(seid  pSeid;  openDescriptor  od;  INTEGER  blockNo; 

148  pBlock  duFile;  asyncld  id)  *>  ioStatus  ios; 

149  $(PBLwriteBlock) 

150  DEFINITIONS 

151  VECT0R0F  fileBlock  vfb  IS  PBLwordsToBlocks (PVMretrieve(pSeid,  duFile)); 

152  EXCEPTIONS 

153  EXCEPTIONSjOF  PVMretrieve (pSeid,  duFile); 

154  EXCEPTI0NS_0F  FCAwriteBlocks (pSeid,  od,  blockNo,  vfb,  id); 

155  EFFECTS 

156  ios  -  EFFECTS__0F  FCAwriteBlocks (pSeid,  od,  blockNo,  vfb,  id); 

157 

158  END  MODULE 
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MODULE: 

CONTENTS: 

TYPE: 

LAST  CHANGED: 


pro. specs  (version  4.11) 
Process  Operators 
SPECIAL. specifications 
12/23/80,  16:56:41 


TYPES 

$(types  supporting  pseudo  interrupts) 

{PROminPiLevel  ..  PROmaxPiLevel) ;  $(pseudo  interrupt  level  range) 
STRUCT_OF(piLevelType  oldPil; 

INTEGER  old Pc; 

INTEGER  oldPs ; 
ipcMessageType  parameter; 

INTEGER  newPc ; 

INTEGER  newPs); 

:  { VECT0R_0 F  piEntryType  piv  | 

LENGTH(piv)  «  PROmaxPiLevel* PROminPiLevel+l } ; 


1  $(" 

2 

3 

4 

5  ") 

6 

7 

8  MODULE  pro 

9 

10  $(  this  module  now  contains  the  material  which  was  formerly  in 

11  the  pro,  ipc  and  pst  modules) 

12 

13 

14 

15 

16  piLevelType: 

17  piEntryType: 

18 

19 

20 
21 
22 

23  piVectorType 

24 

25 

26  $ (types  supporting  ipc) 

27  ipcqType:  {VECT0R  0F  ipcMessageType  zz  |  LENGTH(zz)  <»  IPCmaxMessageCount } ; 

28  ipcTextType:  {VECTOR_OF  CHAR  vc  |  LENGTH (vc )  =  IPCmaxMessageLength} ; 

29  ipcMessageType:  STRUCT_0F(seid  sender;  ipcTextType  text); 

30  pendingType:  STRUCT_0F( BOOLEAN  flag;  INTEGER  time); 

31 

32  $(structure  of  process  status  information) 

33  p rocess Status Type :  STRUCT_OF(seid  self;  $(part  of  the  process  state  that  users  can  state) 

34  seid  parent; 

35  INTEGER  family; 

36  INTEGER  realUser; 

37  INTEGER  realGroup; 

38  INTEGER  advPrio;  $ (advisory  priority) 

39  piLevelType  pil; 

40  INTEGER  ps ; 

41  INTEGER  timerAlarm; 

42  INTEGER  clock; 

43  BOOLEAN  timTog; 

44  INTEGER  supervisorTiming; 

45  INTEGER  userTiming); 

46  processStateType:  STRUCT_0F( INTEGER  pc;  $(program  counter) 

47  VECT0RJ5F  BOOLEAN  vpend; 

48  piVectorType  piv; 

49  ipcqType  ipcq; 

50  processStatusType  pStat); 

51  $(from  smx) 

52  nonDisType:  STRUCT_0F( 

53  INTEGER  securityLevel ;  SET_0F  securityCat  securityCatS; 

54  INTEGER  integrityLevel ;  SET_0F  integrityCat  integrityCatS) ; 

55  daType:  SET_0F  daMode; 

56  modeStruct:  STRUCT  0F(daType  ownerMode,  groupMode,  allMode); 
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57  tUStruct:  STRUCT _0F(nonDisType  nd; 

58  modeStruct  ms;  INTEGER  owner,  group;  SET_0F  privType  priv); 

59 

60 

61  PARAMETERS 

62 

63  INTEGER  PROmaxProcessCount ; 

64 

65  INTEGER  PROminPiLevel ;  $(most  Inter ruptable  pseudo  interrupt  level) 

66  INTEGER  PROmaxPi Level ;  $(least  interruptable  pseudo  interrupt  level) 

67  INTEGER  piZero,piIPC,piTimer,piSignal,piIOC,piHardwareFault; 

68  $(defined  pseudo  interrupt  levels, I/O  completion  pseudo'interupt) 

69 

70  INTEGER  IPCmaxMessageCount ;  $ (maximum  number  of  ipc  messages  per  process) 

71  INTEGER  IPCmaxMessageLength ;  $(maximum  number  of  characters  per  ipc  message) 

72  INTEGER  piPc,  $(program  counter  for  process  invocation  and  spawning“0) 

73  piPs ;  $ (processor  state  for  process  invocation  and  spawning, 

74  154000  octal  =  user  previous  domain,  supervisor  domain, alternate  register 

75 

76  seid  process ExaapleSeid ;  $(any  seid  with  the  tProcess  nsp) 

77  INTEGER  SignalTimeOut ; 

78 

79  DEFINITIONS 

80 

81  BOOLEAN  processExists (seid  pSeid)  IS  PSTprocess State(pSeid)  ?; 

82  seid  newProcessSeid  IS  $(the  process  seid  generation  algorithm) 

33  SENmakeSeid(processExampleSeid,  SENseidIndex( 

84  SOME  seid  s  | 

85  SENseidType(s  )  **  tProcess 

86  AND  NOT  processExists (s )))  ; 

87  INTEGER  processCount  IS 

88  CARDINALITY  {INTEGER  i  |  PSTprocessSlot(i)  ?}); 

89  INTEGER  emptySlot  IS  SOME  INTEGER  i  |  i  INSET  {1  ..  PROmaxProcessCount) 

90  AND  PSTprocess Slot (i)  -  ?; 

91 

92 

93  EXTERNALREFS 

94 

95  FROM  mac: 

96  VFUN  MACclockO  *>  INTEGER  time; 

97 

98  FROM  smx: 

99  seid:  DESIGNATOR; 

100  secureEntltyType :  {tFile,  tDevice,  tTerminal,  tProcess,  tSegment, 


101 

tSubtype,  tExtent,  tNuli); 

102 

privType:  { 

103 

pri vFileUpdateStatus , 

pri vLink, 

104 

prl vLockSeg, 

privModifyPriv, 

105 

privMount , 

privSetLevel, 

106 

privStickySeg, 

pri vSetPath, 

107 

pri vViolSimpSecurity , 

pri  vViolStarSecurity, 

108 

privViolSimpIntegrity , 

pri vViol Star Integrity, 

109 

pri vViolDlscr Access , 

privRealizeExecPermiss ion , 

110 

privSignal , 

privWalkPTable, 

111 

privHalt , 

privKernelCall, 

112 

privViolCompartments , 

pri vSet Comm, 
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( 


i 

j 


113  privlosnigrate 

114  }; 

115 

116  daMode:  {daRead,  daWrite,  daExecute}; 

117  securityCac:  DESIGNATOR; 

118  integrityCat:  DESIGNATOR; 

119  VFUN  SENseldIndex(seid  s)  •>  INTEGER  index; 

120  VFUN  SENseidType(seld  s)  *>  secureEntityType  t; 

121  VFUN  SENmakeSeid(seld  exampleSeid;  INTEGER  index)  *>  seid  rSeid; 

122  VFUN  SMXhas Pri v(seid  pSeid;  privType  priv)  f>  BOOLEAN  b; 

123  VFUN  SMXf low(seid  pSeid,  oSeid;  daType  d)  •>  BOOLEAN  b; 

124  VFUN  SMXdapCseid  pSeid,  oSeiu,  daType  d)  •>  BOOLEAN  b; 

125  VFUN  TIIgetEntityLeveKseid  pSeid,  oSeid)  *>tiiStruct  odi; 

126  VFUN  Tllinf o(seid  s)  *>  tiiStruct  tiis; 

127  OFUN  TIIsetEnt ityLevel (seid  pSeid,  oSied;  tiiStruct  ntii); 

128 

129  FROM  pvm: 

130  segDes:  DESIGNATOR; 

131 

132  FROM  pvp: 

133  OFUN  PVPforkSupport(seid  parent,  child); 

134  OFUN  PVPinvokeSupport(seid  pSeid,  imroSeid;  segDes  arg); 

135  OFUN  PVPspawnSupport(seid  parent,  child,  imSeid;  segDes  arg); 

136  OFUN  PVPreleaseProcessSupport(seid  pSeid); 

137 

138  FROM  fca: 

139  OFUN  FCAcreateOpenTable(seid  pSeid);  $(spawn  support) 

140 

141  FROM  f mi : 

142  OFUN  FMIforkSupport(seid  parent,  child); 

143  OFUN  FMIreleaseSupport(seid  pSeid); 

144 

145 

146  ASSERTIONS 

147  PROminPlLevel  <-  piZero;  piZero  <  pilPC;  pilPC  <  piTimer;  piTimer  <  piSignal;  piSignal  <  p: 

148  pIIOC  <  piHardwareFault ;  plHardwareFault  <=  PROmaxPiLevel ; 

149  $(  ordering  of  defined  pseudo  interrupt  levels) 

150  SENseidType(processExampleSeid )  ■  tProcess; 

151  $ (process ExampleSeid  is  an  example  of  a  process  seid) 

152  processCount  <*•  PROmaxProcess Count ;  $(there  are  never  too  many  processes) 

153  FORALL  seid  s:  SMXflow(s,  process ExampleSeid ,  {daRead}); 

154  $(the  processExampleSeid  can  be  referenced  from  any  security  level) 

155 

156 

157  FUNCTIONS 

158 

159  $(  **••••••'•**•»■•  process  state  functions  *•*******»****•  ) 

160 

161  VFUN  PSTprocessState(seid  pSeid)  *>  processStateType  ps ; 

162  HIDDEN; 

163  INITIALLY  ps  -  ? ; 

164 

165  VFUN  PSTprocessStatus (seid  pSeid)  *>  processStatusType  ps ; 

166  HIDDEN; 

167  DERIVATION  PSTprocessState(pSeid).pStat ; 

168 
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169  VFUN  PSTprocess Slot (INTEGER  n)  *>  seid  ps  ; 

170  HIDDEN; 

171  INITIALLY  ps  -  ? ; 

172 

173  $(  J,**11,,iJ,,1,isupport  for  K_walk_process_table  J »*•»"•**»»" 1 ) 

174 

175  VFUN  PROwalkProcessTable(seld  pSeld;  INTEGER  n)  *>  seid  rSeid; 

176  EXCEPTIONS 

177  XnoPriv:  NOT  pri vWalkPTable  INSET  TIIinfo(pSeid).priv; 

178  XbadSlot :  NOT  n+1  INSET  {1  ..  PROmaxProcessCount } ; 

179  Xerapty:  PSTprocess  Slot  (n)  =»  ?; 

180  DERIVATION 

181  PSTprocess Slot (n ) ; 

182 

183  $(  nniitnmni  support  for  K_nap  ****»»•*»*•****) 

184 

185  VFUN  PSTtimeOfNap(seid  pSeid)  '>  INTEGER  time; 

186  HIDDEN; 

187  INITIALLY  time  =  0; 

188 

189  OFUN  PR0nap(3eid  pSeid;  INTEGER  timeout); 

190  DELAY  WITH  'PSTtimeOf Nap(pSeid )  -  MACclockO; 

191  UNTIL  MACclockO  >=*  PSTtimeOf  Nap(pSeid  )  +  timeout 

192  OR  PSTprocess Status (pSeid). pil  >  pilPC; 

193  $(Wakeup  on  pseudo  interrupt  occurs  when  it  becomes  pending. 

194  After  waking,  the  pseudo  interrupt  is  asserted.) 

195 

196  $(  ""support  for  pseudo  interrupts:  K  signal  and  KinterruptRetum"  "  ) 

197 

198  VFUN  PSTtimeOf Signal (seid  pSeid)  *>  INTEGER  time; 

199  HIDDEN; 

200  INITIALLY  time  -  0; 

201 

202  OFUN  PROsignal(seid  sender,  receiver;  ipcTextType  signalMsg); 

203  DEFINITIONS 

204  piEntryType  receiversSignalEntry( ) 

205  IS  PSTprocessState(receiver).piv{piSignal] ; 

206  EXCEPTIONS 

207  XnoPriv:  NOT  SMXhasPriv(sender ,  privSignal); 

208  XbPrSd:  NOT  (processExis ts ( receiver ) 

209  AND  SMXf low(sender ,  receiver,  {daRead,  daWrite})); 

210  Xunlnt: 

211  NOT  PSTprocessState(receiver).pStat.pil  >  piSignal; 

212  DELAY  WITH  'PSTtimeOf Signal(sender )  -  MACclockO; 

213  UNTIL  MACclockO  >■  PSTtimeOf Signal (sender )  +  SignalTimeOut 

214  OR  PSTprocessState(receiver).pStat.pil  O  piSignal; 

215  ASSERTIONS 

216  processExists(sender); 

217  EFFECTS 

218  'PSTprocessState(receiver).vpend[piSignal]  =  TRUE; 

219  'PSTprocessState (receiver ). pivfpiSigna 1 J . parameter . text  *  signalMsg; 

220  'PSTprocessState(receiver).piv[piSignalJ .parameter. sender  ■  sender; 

221  $ (PROBLEMS 

222  Design  requires  that  K_signal  interrupt  long  kernel  calls.  How  is  this 

223  this  to  be  done?) 

224  $("the  only  Kcalls  which  will  be  interrupted  are  K'nap, 
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225  K_receive  (time  out)  and  a  synchronous  K_read_block 

226  from  the  terminal.  At  least  for  the  K_nap  and  K_receive 

227  delays,  this  can  be  specified  via  another  condition  in  the 

228  PROnap  and  PROreceive") 


230  OFUN  PROinterruptRetum(seid  pSeid); 

231  $(emulates  rti  instruction.  Uses  pseudo  interrupt  vector  entry  associated 

232  with  current  level  and  restores  pc,  ps,  and  pil  to  their  "old"  values) 

233  DEFINITIONS 

234  piEntryType  currentlnterruptEntry 

235  IS  PSTprocess State (pSeid). pi v[PSTpr ocess State (pSeid ).pS tat .pil] ; 

236  EFFECTS 

237  'PSTprocessState(pSeld).pc  *  current InterruptEntry.oldPc ; 

238  'PSTprocessState(pSeid ). pStat . ps  •  currentlnterruptEntry. oldPs ; 

239  'PSTprocessState(pSeid). pStat. pil  -  currentlnterruptEntry. oldPil; 

240 

241  $(  •**»*•»■•»  support  for  ipc:  K_post  and  K_recelve 

242 

243  OFUN  PROpost(seid  sender , receiver ;  BOOLEAN  postPseudoInterrupt; 

244  ipcTextType  text); 

245  $(Detects  security  violation  and  overflow.  Appends  message  to  the  tail  of 

246  the  receivers  ipcq.  Posts  pseudo  interrupt  in  the  receiver  if  requested 

247  and  if  receiver  has  no  pending  receive) 

248  DEFINITIONS 

249  VECTOR  OF  ipcMessageType  queue()  IS  PSTprocessState(receiver). ipcq; 

250  INTEGER  qLength  IS  LENGTH (queue ( ) ) ; 

251  $(There  ARE  exceptions  in  this  function,  but  writing  up  is  permitted 

252  and  the  presence  or  absence  of  an  exception  might  give  information  about 

253  -  the  state  of  a  write'only  object, NOTE  THIS  AND  FIX  IT) 

254  ASSERTIONS 

255  processExists(sender ) ; 

256  EFFECTS 

257  processExis ts (receiver) 

258  AND  SMXf low( sender ,  receiver,  {daWrite}) 

259  AND  qLength  <  IPCmaxMessageLength 

260  AND  SMXdap(sender, receiver ,  {daWrite}) 

261  =>  'PSTprocessState(receiver).ipcq 

262  =  VECT0R(F0R  i  FROM  1  TO  MIN ({ I4q Length ,  IPCmaxMessageLength}) 

263  :  IF  i  O  qLength 

264  THEN  queue()[i] 

265  ELSE  STRUCKsender,  text)); 

266  $(append  new  message  to  receivers  queue) 

267  (postPseudoInterrupt 

268  AND  NOT  PST receivePending( receiver). flag 

269  »>  'PSTprocessState(receiver).vpend[piIPC]  *  TRUE); 

270  $(post  ipc  pseudo  Interrupt  if  required  and  if  receiver  has 

271  no  pending  read) 

272 

273  VFUN  PSTrecei vePending(seid  pSeid)  *>  pendingType  r; 

274  HIDDEN; 

275  INITIALLY  r.flag  -  FALSE  AND  r.time  -  0; 

276 

277  OVFUN  PR0receive(seid  pSeid;  INTEGER  timeout)  *>  ipcMessageType  msg; 

278  $ (Returns  the  ipc  message  at  the  head  of  the  queue  if  one  exists  or  arrives 

279  before  the  expiration  of  timeout.  Otherwise  it  returns  an  exception) 

280  DEFINITIONS 


support  for  ipc:  K_post  and  K_recelve 
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281  VECT0R_0F  ipcMessageType  queueQ  IS  PSTprocessState(pSeid). ipcq; 

282  INTEGER  qLength  IS  LENGTH (queue ()) ; 

283  pendingType  pendingQ  IS  PSTreceivePending(pSeid) ; 

284  EXCEPTIONS 

285  XbNoMes :  qLength  •  0; 

286  DELAY  WITH  'PSTrecelvePending(pSeid).flag  =  TRUE; 

287  'PSTrecelvePending(pSeid).time  =  MACclockO; 

288  UNTIL  qLength  >  0  OR  MACclockO  >=  pendlng( ) . time  +  timeout; 

289  EFFECTS 

290  IF  qLength  >  0  THEN  msg  =  queue()[l]  ELSE  TRUE; 

291  'PSTprocessState(pSeid). ipcq  -  VECT0R(  FOR  i  FROM  1  TO  qLength'l 

292  'PSTreceivePending(pSeid). flag  =  FALSE; 


287  'PSTrecelvePending(pSeid).time  =  MACclockO; 

288  UNTIL  qLength  >  0  OR  MACclockO  >=  pendingO .  time  +  t 

289  EFFECTS 

290  IF  qLength  >  0  THEN  msg  =  queue()[l]  ELSE  TRUE; 

291  'PSTprocessState(pSeid). ipcq  -  VECT0R(  FOR  i  FROM  1  TO  qL 

292  'PSTreceivePending(pSeid). flag  =  FALSE; 

293 

294  $(  *••»**»**  support  for  K_fork  «*»*•***•») 

295 

296  OVFUN  PROfork(seid  parent)  *>  seid  child; 

297  DEFINITIONS 

298  processStateType  p  IS  PSTprocess State (parent ) ; 

299  seid  c  IS  newProcessSeid;  processStatusType  s  IS  p.pStat; 

300  EXCEPTIONS 

301  XnoProc:  processCount+1  >  PROmaxProcessCount ; 

302  EXCEPTIONS_OF  FMIforkSupport (parent ,  c); 

303  EXCEPTI0NS_0F  PVPforkSupport (parent ,  c); 

304  EFFECTS 

305  child  *  c; 

306  'PSTprocessSlot(emptySlot)  «  c; 

307  'PSTprocessState(c)  »  STRUCT(p.pc, 


queue( ) [i+1 ] ) ; 


298 

299 

300  E 

301 

302 

303 

304  E 

305 

306 

307 

308 

309 

310 

311 

312 

313 

314 

315 

316 

317 

318 

319 

320 

321 

322 

323 

324 

325 

326 

327 

328 

329 

330  S( 


VECTORQ, 

VECTORQ, 
p. ipcq, 

STRUCT(c, 

parent, 
s . family, 
s.realUser, 
s . realGroup , 
s . advPrio , 

PROmaxPiLevel , 
s.ps , 

0, 

? 

•  i 

FALSE, 

s .supervisorTiming, 
s . us  erTimtng ) ) ; 

$(this  assertion  specifies  the  initial  tdl  state  of  a  forked  child) 
'TIIinfo(c)  *  Tllinf o(parent) ; 

$(this  assertion  specifies  the  initial  tii  state  of  a  forked  child) 
EFFECTS_0F  FMIf orkSupport(parent ,  c);  $ (provide  and  copy  pofv) 
EFFECTS  OF  PVPforkSupport(parent,  c);  $(provide  virtual  memory) 


support  for  K  invoke 


331 

332  0FUN  PR0invoke(seid  pSeid,  immSeid;  segDes  arg); 

333  DEFINITIONS 

334  processStateType  p  IS  PSTprocessState(pSeid); 

335  processStatusType  s  IS  p.pStat; 

336  tiiStruct  pt  IS  Tllinfo(pSeid) ; 
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337 

333 

339 

340 

341 

342 

343 

344 

345 

346 
34  7 

348 

349 

350 

351 

352 

353 

354 

355 

356 

357 

358 

359 

360 

361 

362 

363 

364 

365  $( 

366 


EXCEPTION’S 

£XCEPTI0NS_0F  PVPinvokeSupport (pSeid,  imraSeid,  arg); 

ASSERTIONS 

processExists (pSeid) ; 

EFFECTS 

'PSTprocessState(pSeid)  =  STRUCT(piPc, 

VECTOR (), 

VECTOR (), 

VECT0RO. 

STRUCT (s. self , 

s • parent , 
s ■ family, 
s .  realUser , 
s . realGroup , 
s . advPrio, 

PROmaxPiLevel , 
piPs  , 

0, 

? 

FALSE , 

0, 

0)); 

$(assertion  defines  thes  initial  process  state  of  the  invoked  intermediary) 
'TIIinfo(pSeid)  *  STRUCT(pt.nd,  pt.ms,  pt. owner,  pt. group, 

Til inf o(immSeid ). priv) ; 

$(this  is  how  the  post'invoke  process  gets  the  intermeds  privileges) 
EFFECTSOF  PVPinvokeSupport(pSeid,  immSeid,  arg);  $(redo  virtual  memory) 

in  ii  maim*  support  for  Kjspawn  *»•»»*  iiiiii  1 1 ) 


367  OVFUN  PROspawn(seid  parent,  immSeid;  segDes  arg)  •>  seid  child; 


368 

369 

370 

371 

372 

373 

374 

375 

376 

377 

378 

379 

380 

381 

382 

383 

384 

385 

386 

387 

388 

389 

390 

391 

392 


DEFINITIONS 

process StateType  p  IS  PSTprocessState(parent;; 
processStatusType  s  IS  p.pStat; 
tiiStruct  pt  IS  Tllinfo(parent); 
seid  c  IS  newProcessSeid ; 

EXCEPTIONS 

XnoProc:  process Count+1  >  PROmaxProces s Count ; 
EXCEPTI0NS_0F  PVPspawnSupport(parent ,  c,  immSeid,  arg); 
EXCEPTI0NS_0F  FCAcreate0penTable(parent ) ; 

ASSERTIONS 

processExists (parent ) ; 

EFFECTS 
child  ”  c; 

'PSTprocessSlot(emptySlot)  -  c; 

'PSTprocessState(c)  ■  STRUCT(piPc, 

VECT0RO, 

VECT0RO, 

VECT0RO, 

STRUCT (c, 

s. parent, 
s . family, 
s. realUser, 
s . realGroup, 
s. advPrio, 
PROmaxPiLevel, 
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393  piPs, 

394  0, 

395  ?, 

396  FALSE, 

397  0, 

398  0)); 

399  $(the  process  state  of  the  newly  spawned  Intermediary) 

400  'TIIinfo(c)  «  STRUCT(pt . nd ,  pt.ms,  pt. owner,  pt. group, 

401  Tllinf o(immSeid).priv); 

402  $(post'spavn  child  acquires  intermediatarys  privileges) 

403  EFFECTSOF  PVPspawnSupport(parent ,  c,  immSeid,  arg);  $(create  vm) 

404  EFFECTSJDF  FCAcreat eOpenTable (c ) ;  $(create  pofv) 

405 

406  $(  * • 1  *  •  • *  support  for  K_release_process  •••••••••••**•*) 

407 


408  OFUN  PR0releaseProcess(seid  pSeid,  rSeid); 

409  $(Typically  a  process  will  release  Itself  and  pSeid=rSeld.  However  this 

410  is  not  treated  as  a  special  case.) 

411  EXCEPTIONS 

412  XbPrSd:  (NOT  processExists (rSeid)) 

413  OR  (NOT  SMXf low(pSeid,  rSeid,  {daRead,  daWrite})) 

414  OR  ((TI Iinfo(rSeid  ). owner  ~*=  Tllinfo(pSeid). owner)) 

415  AND  NOT  SMXhasPri v(pSeid,  pri vSetLevel ) ; 

416  ASSERTIONS 

417  processExists (pSeid  ) ; 

413  EFFECTS 

419  'PSTprocessSlot (SOME  INTEGER  i  |  PSTprocessSlot(i)  -  rSeid)  -  ?; 

420  'PSTprocessState(rSeid)  -  ?; 

421  'TIIinfo(rSeid)  -  ?; 

422  EFFECTS_OF  FMIreleaseSupport (rSeid ) ; 

423  EFF£CTS_0F  PVPreleaseProcessSupport(rSeid) ; 

424 

425  $(  •*•••*•••••••••  status  getting  and  setting  *••*»•••••»»•••) 

426 

427  VFUN  PROgetProcessStatus (seid  pSeid,  oSeid)  4>  processStatusType  ps ; 

428 

429 

430 

431 

432 

433 

434 

435 

436 

437 

438 

439 

440 

441 

442 

443 

444 

445 

446 

447 

448 
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DEFINITIONS 

processStatusType  s  IS  PSTprocess Status (oSeid ); 
EXCEPTIONS 

XbPrSd:  NOT  (processExists(oSeid) 

AND  SMXf low(pSeid ,  oSeid,  {daRead}) 
AND  SMXdap(pSeid, oSeid,  {daRead})); 

ASSERTIONS 

processExists(pSeid) ; 

DERIVATION 

STRUCT (s . self , 

s  .parent , 
s . family , 
s . realUser , 
s . realGroup , 
s . advPrio, 
s  .pil , 
s .  ps  , 

s . timerAla rra, 

MACclockQ  , 
s . timTog , 

s  .supervisorTiming, 
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449  s.userTlmlng); 

450 


451  OFUN  PROsetProcess Status (seid  pSeid,  oSeid;  process StatusType  n); 


452 

453 

454 

455 

456 

457 

458 

459 

460 

461 

462 

463 

464 

465 

466 

467 

468 

469 

470 

471 

472 

473 

474 

475 

476 

477 

478 

479 

480 

481 


DEFINITIONS 

processStateType  e  IS  PSTprocessState(oSeld) ; 
processStatusType  o  IS  PSTprocess Status (oSeid) ; 

EXCEPTIONS 

XbPrSd:  (NOT  processExis ts (oSeid)) 

OR  (NOT  SMXf low(pSeid,  oSeid,  {daRead,  daWrite})) 

OR  ((Tllinfo(oSeid). owner  Tllinfo(pSeid). owner)) 

AND  NOT  SMXhasPriv (pSeid,  privSetLevel); 

EXCEPTI0NS_0F  PRO re lease Process (pSeid , oSeid ) ; 

ASSERTIONS 

process  Exists (pSeid); 

EFFECTS 

'PSTprocessState(oSeid)  ■  STRUCT(e.pc, 

e. vpend , 

e.piv, 

e.ipcq, 

STRUCT(o.self , 

o. parent , 
n. family, 
n. realUser, 
n. realGroup, 
n.advPrio, 
n. pil, 
n.  ps , 

n.  t  imerAlarm, 

? 

*  * 

n.  timTog, 

o .  super vis  orTiming , 
o.userTiming)) ; 

END  MODULE 
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pvm. specs 

1  $(" 

2 

3 

4 

5  ”) 

6 

7 

8  MODULE  pvm 

9 

10  $(  this  module  now  contains  the  contents  of  what  was  the  seg  and  pvm  modules) 

11 

12  TYPES 

13 

14  $(FR0M  mac) 

15  vAddrType:  {0  MACmaxVaddr } ; 

16  $  (FROM  snix  "  til) 

17  daType:  SET_OF  daMode ; 

18  modeStruct:  STRUCT _0F(daType  ownerMode,  groupMode ,  allMode); 

19  domainType :  {null Domain , kerne IDomain , supe r vis orDo main, user Domain } ; 

20  nonDisType:  STRUCT_0F( 

21  INTEGER  securityLe vel ;  SET_0F  securityCat  securityCatS ; 

22  INTEGER  integrityLevel ;  SET_0F  integrityCat  integrityCatS) ; 

23  tiiStruct:  STRUCT_0F(nonDisType  nd ; 

24  modeStruct  ms;  INTEGER  owner,  group;  SET  OF  privType  priv); 

25  $(from  seg  11  exportable) 

26  segDes :  DESIGNATOR; 

27  spaceType:  {nullSpace,  iSpace,  dSpace}; 

28  direction:  {up,  down}; 

29  $(frora  seg  11  redeclarable) 

30  virtualLocat ion : 

31  STRUCT_OF(domainTvpe  domain;  spaceType  idSpace;  vAddrType  vAddr); 

32  $(from  seg  "  local) 

33  globalData: 

34  STRUCT_0F( BOOLEAN  sharable,  swappable,  sticky,  memAdvlse,  executable); 

35  ins tanceStruct : 

36  STRUCT_OF(globalData  gl;  direction  growth;  INTEGER  refCount; 

37  VECT0R_0F  INTEGER  data); 

38  useStruct:  STRUCT_OF(seid  instance;  virtualLocation  vloc;  daType  da); 

39  $(from  pvm  **  redeclarable) 

40  pBlock:  STRUCT  0F(virtualLocation  vloc;  INTEGER  size); 

41  statusStruct : 

42  STRUCT_0F(globalData  gl;  direction  growth;  INTEGER  size;  seid  iseid; 

43  segDes  udes  ;  virtualLocation  vloc;  daType  da;  BOOLEAN  mapped); 

44 

45 

46  PARAMETERS 

47 

48  $(from  seg)seid  exarapleSegmentSeid ;  $(used  for  segment  creation) 

49  segDes  SEGnullSeg;  $(  indicates  null  segment  designator) 

50  INTEGER  PVMmaxSegDes ;  $(maximum  number  of  segment  designators  in  an  address 

51  space) 

52 

53 

54  DEFINITIONS 

55 

56  $(f rom  seg) 


Page  1  Wed  Mar  18  11:13:19  1981 


MODULE: 
CONTENTS : 
TYPE: 

LAST  CHANGED: 


pvm. specs  (version  4.11) 
Virtual  Memory 
SPECIAL. specif ications 
12/23/80,  17:37:23 


Version  4.4 


-114- 


WDL-TR7932 


pvm. specs 


Page  2  Wed  Mar  18  11:13:19  1981 


57  INTEGER  SECsize(seid  segSeid)  IS  LENGTH (SEGinstancelnf o(segSeid).data) ; 

58 

59  $(from  pvm) 

60  INTEGER  nSegs(seid  pSeid) 

61  IS  CARDINALITY {segDes  sd  |  SEGuseInfo(pSeid,  sd)  ?}); 

62 

63  BOOLEAN  PVMvmF.xists(seid  pSeid)  IS  PVMsegmentSet(pSeid)  ~m  ?; 

64 

65  segDes  PVMblockToSeg(seid  pSeid;  pBlock  block)  IS 

66  SOME  segDes  sd 

67  |  sd  INSET  PVMmappedSegmentSet(pSeid ) 

68  AND  (EXISTS  useStruct  use  -  SEGuseInfo(pSeid,  sd) 

69  :  use. vloc. domain  =  block. vloc. domain 

70  AND  use.  vloc.  idSpace  =*  block,  vloc .  idSpace 

71  AND  use . vloc . vAddr  <=  block. vloc. vAddr 

72  AND  block. vloc . vAddr  +  block. size 

73  <»  use . vloc . vAddr  +  SEGsize(use. instance )) ; 

74  $(  gives  the  segment  designator,  if  any,  that  totally  contains  block  in 

75  address  space  designated  by  pSeid;  if  there  is  none,  returns  ?;  the 

76  segment  must  be  mapped) 

77 

78  SET_0F  INTEGER  addrRegRange (INTEGER  vAddr,  size;  direction  d)  IS 

79  IF  d  3  up 

80  THEN  {vAddr  /  MACmaxOffset  ..  (vAddr  +  size  *  1)  /  MACmaxOf fset } 

81  ELSE  {(vAddr  1  size  +  1)  /  MACmaxOffset  ..  vAddr  /  MACmaxOffset}; 

82  $(  gives  the  range  of  address  registers  used  by  a  segment  as  a  function  of 

83  its  start  address,  size,  and  growth  direction) 

84 

85  SET_0F  INTEGER  addrRegRangeSeg (seid  pSeid;  segDes  s)  IS  ? 

86  LET  useStruct  use  =  SEGuseInfo(pSeid,  s) 

87  IN  addrRegRange(use .vloc. vAddr ,  SEGsize(use . ins tance ) , 

88  SEGins  tanceInfo(use. ins tance ). growth) ; 

89  $(  gives  the  range  of  address  registers  used  by  a  segment  as  a  function  of 

90  the  process  id  and  the  segment  designator) 

91 

92  BOOLEAN  noHole(seid  pSeid;  INTEGER  size;  virtualLocation  vl ;  direction  d; 

93  SET_0F  segDes  ssd)  IS 

94  NOT  add rRegRange( vl. vAddr ,  size,  d)  SUBSET  {0  ..  MACmaxReg} 

95  OR  ( EXI5TS  segDes  s  |  s  INSET  ssd;  useStruct  use  “  SEGuseInfo(pSeid,  s) 

96  :  use. vloc . idSpace  =  vl. idSpace 

97  AND  use. vloc. domain  *  vl. domain 

98  AND  addrRegRangeSeg (pSeid,  s) 

99  INTER  addrRegRange (vl. vAddr,  size,  d)  {}); 

100  $(TRUE  iff  a  segment  described  by  size,  vl,  and  direction  will  NOT  fit  into 

101  a  hole  in  the  address  space  designated  by  pSeid  and  ssd;  this  includes 

102  testing  for  virtual  memory  underflow  and  overflow) 

103 

104  EXTERNALREFS 

105 

106  FROM  mac: 

107  INTEGER  MACmaxVaddr,  MACmaxOffset,  MACmaxReg; 

108 

109  FROM  smx : 

110  $(FR0M  sen: ) 

111  seid:  DESIGNATOR; 

112  secureEntityType :  {tFile,  tDevice,  tTerminal,  tProcess ,  tSegment,  tSubtype, 
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113  tExtent ,  tN’ull}; 

114  VFUN  SENseidNsp(seid  s)  *>  INTEGER  nsp; 

115  VFUN  SENseidIndex(seid  s)  *>  INTEGER  index; 

116  VFUN  SENaakeSeid(s eid  exampleSeid;  INTEGER  index)  *>  seid  outSeid; 

117  VFUN  SENseldType(seid  s)  J>  secureEntityType  set; 


118 

$(FR0M  prv: ) 

119 

privType:  { 

120 

privFileUpdateStatus , 

privLink, 

121 

privLockSeg, 

privModif yPriv, 

122 

pri vMount , 

pri vSetLevel , 

123 

privStickySeg , 

pri vSetPath , 

124 

privViolSimpSecurity , 

privViolStarSecurity , 

125 

pri vVio IS imp Integrity, 

pri vVialStar Integrity, 

126 

pri vViolDiscrAccess , 

pri vRealizeExec Permission, 

127 

privSignal, 

pri vWalkPTable, 

128 

prlvHalt, 

privKerne ICall , 

129 

pri vVioICompartments , 

privSetComm, 

130 

pri vlmmigrate 

131 

}; 

132 

$ (FROM  tii : ) 

133 

securityCat:  DESIGNATOR; 

134 

integrityCat :  DESIGNATOR; 

135 

daMode:  {daRead,  daWrite,  daExecute}; 

136 

VFUN  Tllinf o(seid  anySeid)  *>  tiiStruct  tiiSt; 

137 

$(FROM  smx: ) 

138  VFUN  SMXhasPri v(seid  pSeid;  privType  priv)  *>  BOOLEAN  b; 

139  VFUN  SMXf low(seid  pSeid,  oSeid;  daType  d)  •>  BOOLEAN  b; 

140  VFUN  SMXdap(seid  pSeid,  oSeid;  daType  d)  •>  BOOLEAN  b; 

141 

142 

143  ASSERTIONS 

144  $(from  seg) 

145  MACmaxVaddr  >  0;  MACmaxOffset  >  0;  MACmaxReg  >  0; 

146  MACmaxVaddr  +  1  ■  (MACmaxOf fset  +  1)  *  (MACmaxReg  +  1); 

147  PVMmaxSegDes  >*  2; 

148  $(  basic  relations  among  the  SEG  parameters) 

149  SENseidType (examp leSegmentSeid )  *  tSegment; 

150  $(  basic  property  of  exampleSegmentSeid  and  all  segment  seids) 

151  FORALL  seid  s  I  SEGinstanceInfo(s )  ? 

152  :  SENseidNsp (s )  *  SENseidNsp(exampleSegmentSeid ) ; 

153  $(all  seids  for  existing  segments  have  a  dis tinbuished  nsp  component) 

154  FORALL  seid  s  I  SEGinstanceInfo(s )  ?  :  Tllinfo(s)  “■  ?; 

155  $(all  existing  segments  have  an  exiting  TII  entry) 

156  FORALL  seid  pSeid;  segDes  segd  |  SEGuselnf o(pSeid,  segd)  ? 

157  :  SEGinstanceInfo( SEGuselnf o(pSeid,  segd )• Instance  )  “■  ?; 

158  $(all  valid  segment  uses  have  corresponding  valid  segment  instances) 

159 

160  $(from  pvm) 

161  FORALL  seid  pSeid  |  PVMvmExists (pSeid);  segDes  sd 

162  :  (sd  INSET  PVMsegmentSet(pSeid))  »  (SEGuselnf o(pSeid,  sd)  ?); 

163  $(defines  what  it  means  for  a  segment  tc  be  in  the  segment  set  of  a 

164  process) 

165  FORALL  seid  pSeid  |  PVMvmExis ts (pSeid ) 

166  :  PVMmappedSegmentSet (pSeid)  SUBSET  PVMsegmentSet (pSeid ) ; 

167  $(only  existing  segments  can  be  mapped) 

168  FORALL  seid  pSeid 1 ,pSeid2;  segDes  sdl,sd2: 
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169  NOT  SEGlns Cancelnf o(SEGuseInf o(pSeidl , sdl ) . instance ) . gl . sharable 

170  -> 

171  (SEGuseInfo(pSeidl , sdl). instance  ”«  SEGuselnf o(pSeid2,sd2). Instance); 

172  $(A  nonsharable  instance  struct  cannot  be  pointed  to  by  more  than  1 

173  use  struct.  Checked  for  in  PVMrendezvous . ) 

174  FORALL  seid  pSeid  !  PVMvmExists (pSeid);  segDes  si;  segDes  s2 

175  :  LET  useStruct  usel  ■  SEGuselnf o(pSeid ,  si); 

176  useStruct  use2  »  SEGuseInfo(pSeid,  s2) 

177  INsl~*s2  AND  usel  ?  AND  use 2  “*  ? 

178  AND  {si,  s 2}  SUBSET  PVMmappedSegmentSet (pSeid) 

179  AND  use l.vloc. domain  =  use2.vloc. domain 

180  AND  usel.  vloc.  id  Space  =*  use2.  vloc.  idSpace 

181  ->  addrRegRangeSeg(pSeid ,  si)  INTER  addrRegRangeSeg(pSeid,  s2)  »  {}; 
132  $(no  two  mapped  segments  in  the  same  domain  and  idSpace  may  have 

183  overlapping  memory  address  registers) 

184 

185 

186  FUNCTIONS 

187 

188  state  functions  *'iuiinnniiimniiiimii) 

189 

190  VFUN  SEGinUselndexSetO  J>  SET_0F  INTEGER  si;  $(SEGinUseIndexSet ) 

191  $(  gives  the  set  of  seid  indices  that  are  currently  in  use  for  existing 

192  segments ) 

193  HIDDEN; 

194  INITIALLY  si  -  {}; 

195 

196  VFUN  SEGinstanceInfo(seid  segSeid)  *>  instanceStruct  is;  $(SEGinstanceInf o) 

197  $(  gives  all  the  information  pertaining  to  a  segment's  global  data, 

198  referred  to  as  segment  in  tance  data) 

199  HIDDEN; 

200  INITIALLY  is  -  ? ; 

201 

202  VFUN  SEGuseInfo(seid  pSeid;  segDes  segd)  J>  useStruct  us;  S(SEGuselnfo) 

203  $(  gives  all  the  information  pertaining  to  a  segment's  use  in  the  address 

204  space  in  a  particular  process;  this  is  information  local  to  a  process) 

205  HIDDEN; 

206  INITIALLY  us  -  ? ; 

207 

208  VFUN  PVMsegmentSet(seid  pSeid)  *>  SET_0F  segDes  segSet;  $(PVMsegmentSet) 

209  $(  gives  the  set  of  segments  possessed  by  a  given  process) 

210  INITIALLY  segSet  -  ?; 

211 

212  VFUN  PVMmappedSegmentSet(seid  pSeid)  *>  SET_0F  segDes  mappedSet; 

213  $ (PVMmappedSegmentSet ) 

214  $(  gives  the  set  of  mapped  **  or  active  segments  “  of  a  process;  a 

215  segment  cannot  be  addressed  unless  it  is  mapped) 

216  HIDDEN; 

217  INITIALLY  mappedSet  -  ?; 

218 

219  $(»  •* » •  i  < *  * i *  * » •* *  *  ii  *  i*  virtual  memory  management  *•*•»»*•***•»•»**••••*»••) 

220 

221  CFUN  PVMcreateVM(seld  pSeid);  S(PVMcreateVM) 

222  $(  creates  a  new  virtual  memory  to  be  Identified  by  "pSeid";  this  VM 

223  must  not  currently  exist) 

224  ASSERTIONS 
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225  MOT  PVMvmExists(pSeid); 

226  EFFECTS 

227  'PVMsegmentSet (pSeid )  *■  {}; 

228  'PVMmappedSegment Set (pSeid)  ■  {}; 

229 

230  OF UN  PVMdeleteVM(seid  pSeid);  $(PVMdeleteVM) 

231  $(  deletes  the  currently  existing  virtual  memory  "pSeid") 

232  ASSERTIONS 

233  PVMvmExists (pSeid); 

234  EFFECTS 

235  'PVMsegmentSet(pSeid)  *  ?; 

236  'PVMmappedSegmentSet (pSeid)  -  ?; 

237 

238  5(**<'»nnuui  basic  segment  management 

239 

240  OFUN  PVMstore (seid  pSeid;  pBlock  block;  VECT0R_0F  INTEGER  vec);  $(PVMstore) 

241  $(inserts  contents  of  vec  into  the  mapped  segment  indicated  by  block) 

242  DEFINITIONS 

243  segDes  targ  IS  PVMblockToSeg(pSeid,  block); 

244  useStruct  use  IS  SEGuselnfo (pSeid ,  targ); 

245  instanceStruct  inst  IS  SEGins tancelnf o (use . ins tance ) ; 

246  EXCEPTIONS 

247  XbAddr :  targ  =  ?; 

248  XbadDa:  NOT  daWrite  INSET  use. da; 

249  XbSgRng:  LENGTH (vec)  block.size; 

250  XbSgSz :  block.size  <-  0;  $( IMPOSSIBLE,  CARDINAL) 

251  ASSERTIONS 

252  PVMvmExists (pSeid); 

253  EFFECTS 

254  LET  INTEGER  relOffset  *  block. vloc. vAddr  *  use.vloc.vAddr 

255  IN  'SEGinstanceInfo(use . instance)  * 

256  STRUCT ( ins t .gl ,  inst. growth,  inst . ref Count , 

257  VECT0R( 

258  FOR  i  FROM  1  TO  LENGTH (inst .data) 

259  :  IF  i  INSET  {relOffset  +  1  ..  relOffset  +  LENGTH (vec)} 

260  THEN  vec [i  *  relOffset] 

261  ELSE  ins t. data [i] )) ; 

262 

263  VFUN  PVMretri eve (seid  pSeid;  pBlock  block)  *>  VECTORjOF  INTEGER  vec; 

264  $(  retreives  data  from  a  mapped  segment  as  specified  by  pBlock) 

265  DEFINITIONS 

266  segDes  targ  IS  PVMblockToSeg (pSeid ,  block); 

267  useStruct  use  IS  SEGuseInfo(pSeid,  targ); 

268  instanceStruct  inst  IS  SEGins tancelnf o(use . ins tance) ; 

269  EXCEPTIONS 

270  XbSgSz :  block.size  <«  0;  $(IMP0SSIBLE  CARDINAL) 

271  XbSgDes:  targ  -  ?; 

272  ASSERTIONS 

273  PVMvmExis  ts (pSeid) ; 

274  DERIVATION 

275  VECT0R(F0R  i  FROM  1  TO  block.size: 

276  inst. datafblock. vloc. vAddr  *  use.vloc.vAddr  +  i  *  1]); 

277 

278  0VFUN  PVMbuild(seid  pSeid;  statusStruct  st;  modeStruct  ms) 

279  *>  STRUCT_OF(seid  segSeid;  segDes  segd)  result;  $(PVMbuild) 

280  $(  builds  a  new  segment  with  the  specified  parameters; 
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281  an  entry  In  the  til  table  i  also  created  for  the  segment; 

282  the  results  are  the  14  previously  unused  41  seid  for  the  new  segment  and 

283  the  44  previously  unused  44  segment  designator;  the  newly  created 

284  segment  is  mapped,  indicating  that  it  can  be  addressed  inmediately ; 

285  discretionary  access  that  the  process  allows  itself  to  the  segment,  "m" 

286  must  be  a  subset  of  the  owner  access  specified  in  the  til  information; 

287  "ms"  of  the  new  segment  must  be  within  the  size  limitations  and  fit  into 

288  the  mapped  virtual  memory  space  of  the  creating  process) 

289  DEFINITIONS 

290  tiiStruct  proTii  IS  Tllinf o(pSeid); 

291  tiiStruct  segTii 

292  IS  STRUCT(proTii.nd,  ms,  proTii. owner,  proTii . group ,  proTii. priv); 

293  seid  newSegSeid 

294  IS  SENmakeSeld(exampleSegraentSeid , 

295  SOME  INTEGER  i  |  NOT  i  INSET  SEGinUselndexSetO) ; 

296  segDes  sd  IS  SOME  segDes  sdl  |  SEGuselnf o(pSeid ,  sdl)  ■  ?; 

297  EXCEPTIONS 

298  XnPvStkSg:  st.gl. sticky 

299  AND  NOT  SMXhasPriv(pSeid ,  privStickySeg); 

300  XnPvLkSg:  NOT  st . gl . swappable  AND  NOT  SMXhasPriv(pSeid,privLockSeg) ; 

301  XbadMode :  ((daWrite  INSET  ms.ownerMode  AND  NOT 

302  daRead  INSET  ms.ownerMode)  OR  (daWrite  INSET  ms.groupMode 

303  AND  NOT  daRead  INSET  ms.groupMode)  OR  (daWrite  INSET 

304  ms.al IMode  AND  NOT  daRead  INSET  ms .allMode)) ; 

305  XbSgSz :N0T  st.size  INSET  {1  ..  MACmaxVaddr } ; 

306  $(test  made  only  for  0;ll/7G,s  card)  $ 

307  XvrtMcCf 1 : 

308  noHole(pSeid,  st.size,  st.vloc,  st. growth,  PVMmappedSegmentSet (pSeid) ) ; 

309  XpostEh:  nSegs(pSeid)  >=  PVMmaxSegDes ; 

310  RES0URCEERR0R;  $(  ran  out  of  table  space  or  seid  space) 

311  ASSERTIONS 

312  PVMvmExis ts (pSeid) ; 

313  EFFECTS 

314  'TIIinfo(newSegSeid)  ■  segTii; 

315  'SEGinUselndexSetO 

316  ”  SEGinUselndexSetO  UNION  {SENseidlndex(newSegSeid)} ; 

317  'SEGinstancelnf o(newSegSeid)  =* 

318  STRUCT(st.gl,  st. growth,  1, 

319  VECT0R(F0R  i  FROM  1  TO  st.size  :  0)); 

320  'SEGuselnf oCpSeid,  sd)  *  STRUCT (newSegSeid ,  st.vloc,  ms.ownerMode); 

321  result  »  STRUCT(newSegSeid,  sd); 

322  'PVMsegmentSet(pSeid)  ■  PVMsegraentSet (pSeid )  UNION  {sd}; 

323  'PVMmappedSegmentSet (pSeid) 

324  =  PVMmappedSegmentSet (pSeid )  UNION  {sd}; 

325 

326  0FUN  PVMdes troy (seid  pSeid;  segDes  segd);  $(PVMdestroy) 

327  $(destroys  the  segment  use  indicated  by  pSeid  and  segd;  if  the  segment  is 

328  unsticky  and  otherwise  unreferenced,  the  segment  instance  information  is 

329  also  deleted) 

330  DEFINITIONS 

331  useStruct  use  IS  SEGuselnf o(pSeid ,  segd); 

332  seid  segSeid  IS  use. instance ; 

333  instanceStruct  inst  IS  SEGinstancelnfo(segSeid); 

334  EXCEPTIONS 

335  K.EsegNotHeld :  NOT  segd  INSET  PVMsegraentSet  (pSeid ) ; 

336  ASSERTIONS 
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337  PVMvmExlsts (pSeid); 

338  EFFECTS 

339  'PVMsegmentSet (pSeid)  -  PVMsegmentSet(pSeid)  DIFF  {segd}; 

340  'PVMmappedSegmentSet (pSeid)  ■  PVMmappedSegmentSet (pSeid)  DIFF  (segd); 

341  'SEGuseInfo(pSeid,  segd)  “  ?; 

342  IF  ( ins t . ref Count  “  1  AND  inst. gl. sticky  «  FALSE) 

343  THEN  'SEGinstanceInfo(segSeid )  -  ? 

344  AND  'SEGinUselndexSetO 

345  »  SEGinUselndexSet ( )  DIFF  {SENseidlndex(segSeid)} 

346  AND  'TIIinfo(segSeid)  -  ? 

347  ELSE  'SEGinstanceInfo(segSeid )  * 

348  STRUCT ( ins t .gl,  inst. growth,  inst • ref Count  J  1,  inst.data); 

349 

350  $(»»»*»*»****»•**•**•**•*•  high  level  storage  allocation  •••niiuiiiimiii) 

351 

352  OFUN  PVMremap (seid  pSeid;  segDes  in;  virtualLocation  vl  ;  daType  d; 

353  BOOLEAN  vlFlg,  daFlg;  segDes  out;  INTEGER  newSize; 

354  BOOLEAN  ns  Fig);  $( PVMremap) 

355  $(  this  function  takes  the  currently  mapped  segment  "out"  and  maps  it  out, 

356  while  simultaneously  mapping  in  the  currently  unmapped  segment  "in"; 

357  this  function  can  be  used  for  mapping  in  *•  without  mapping  out  11  by 

358  letting  "out"  be  the  distinguished  value  SEGnullSeg;  similarly,  mapping 

359  out  alone  can  be  done  by  letting  "in"  be  SEGnullSeg;  a  mapped  in  segment 

360  can  have  a  new  virtual  location  and  a  discretionary  access  specified 

361  optionally;  a  mapped  out  segment  can  have  its  size  optionally  changed; 

362  all  these  optional  changes  are  specified  by  the  values  of  BOOLEAN  flags; 

363  the  idSpace  of  the  mapped  in  segment  may  not  be  changed;  the  mapped  in 

364  segment  must  occupy  a  hole  in  the  virtual  memory) 

365  DEFINITIONS 

366  SET_0F  segDes  inSet  IS  IF  in  -  SEGnullSeg  THEN  {}  ELSE  {in}; 

367  SET_0F  segDes  outSet  IS  IF  out  ■*  SEGnullSeg  THEN  {}  ELSE  {out}; 

368  useStruct  inUse  IS  SEGuseInfo(pSeid,  in); 

369  instance Struct  inlnst  IS  SEGinstanceInfo( inUse. instance) ; 

370  useStruct  outUse  IS  SEGuseInfo(pSeid,  out); 

371  seid  outSeid  IS  outUse. instance ; 

372  instanceStruct  outlnst  IS  SEGinstancelnfo(outSeid) ; 

373  EXCEPTIONS 

374  XbSgDes:  NOT  inSet  SUBSET  PVMsegmentSet (pSeid ) ; 

375  XoutSgAldUmp:  NOT  outSet  SUBSET  PVMmappedSegment Set (pSeid) ; 

376  XwOnlSg:  daFlg  AND  daWrite  INSET  d  AND  NOT  daRead  INSET  d; 

377  XinSgAldMap :  {in}  SUBSET  PVMmappedSegmentSet(pSeid); 

378  XvrtMcCfl : 

379  in  SEGnullSeg 

380  AND  noHole(pSeid,  SEGsize(inUse . ins tance ) , 

381  IF  vlFlg  THEN  vl  ELSE  inUse. vloc,  inlnst .growth, 

382  PVMmappedSegmentSet (pSeid)  DIFF  outSet); 

383  XbNewSz : 

384  nsFlg  AND  (NOT  newSize  INSET  {1  ..  MACmaxVaddr} 

385  OR  outlnst. gl.sharable 

386  OR  NOT  daWrite  INSET  outUse. da); 

387  RES0URCE_ERR0R;  $(for  swaps  pace  upon  segment  growth) 

388  ASSERTIONS 

389  PVMvmExlsts (pSeid); 

390  EFFECTS 

391  'PVMmappedSegmentSet (pSeid)  *  (PVMmappedSegmentSet (pSeid)  DIFF  outSet) 

392  UNION  inSet; 
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393  'SEGuselnf o( pSeid,  in) 

394  -  STRUCK inUse. instance ,  IF  vlFlg  THEN  vl  ELSE  inUse. vloc, 

395  IF  daFlg  THEN  d  ELSE  inUse. da); 

396  (nsFlg  AND  newSize  “•  SEGsize(inUse . ins tance)) 

397  =*>  /SEGinstanceInfo(outSeid) 

393  •  STRUCT (out Ins t .gl ,  outlnst .growth ,  out  Ins t . ref Count , 

399  VECTOR(FOR  i  FROM  1  TO  newSize 

400  :  IF  i  <-  SEGsize(outSeid) 

401  THEN  outlnst. data[i]  ELSE  0)); 

402 

403  5(n*H*iimimuinnii  segment  sharing  •••••iiiiiiiinmiiiiiiimiiiii) 

404 

405  OVFUN  PVMrendezvous (seid  pSeid,  segSeid;  virtualLocation  vl;  daType  d) 

406  *>  segDes  sd;  $ (PVMrendezvous ) 

407  $(  creates  a  use  for  the  segment  named  by  segSeid;  this  segment  appears 

408  inaccessible  if  the  multilevel  security  model  would  consider  it  a 

409  violation  of  information  flow) 

410  DEFINITIONS 

411  instanceStruct  inst  IS  SEGinstancelnfo(segSeid); 

412  segDes  segd  IS  SOME  segDes  sdl  |  SEGuseInfo(pSeid,  sdl)  »  ?; 

413  EXCEPTIONS 

414  KEsegBadName : 

415  NOT  (Inst  ? 

416  AND  (IF  daWrite  INSET  d 

417  THEN  SMXf low(pSeid,  segSeid,  {daRead,  daWrite}) 

418  ELSE  SMXf low(pSeid ,  segSeid,  {daRead}))); 

419  XbadDa :  NOT  SMXdap(pSeid,  segSeid,  d); 

420  XdupSg:  EXISTS  segDes  sdl 

421  :  SEGuseInfo(pSeid,  sdl) . instance  «  segSeid; 

422  XwOnlSg :  daWrite  INSET  d  AND  NOT  daRead  INSET  d; 

423  XvrtMmCfl:  noHole(pSeid,  SEGsize(segSeid) ,  vl,  inst. growth, 

424  PVMmappedSegmentSet (pSeid )) ; 

425  XpostEh:  nSegs(pSeid)  >*  PVMmaxSegDes ; 

426  XnotSh:  NOT  inst.gl.sharable; 

427  ASSERTIONS 

428  PVMvmExists (pSeid) ; 

429  EFFECTS 

430  'SEGuselnf o( pSeid,  segd)  »  STRUCT(s egSeld,  vl,  d); 

431  'SEGinstancelnf o(segSeid ) 

432  *  STRUCT(inst .gl , inst .growth ,  inst. refCount  +  1,  inst. data); 

433  'PVMsegmentSet (pSeid)  -  PVMsegmentSet (pSeid )  UNION  {segd}; 

434  'PVMmappedSegmentSet (pSeid) 

435  *  PVMmappedSegmentSet (pSeid )  UNION  {segd}; 

436  sd  m  segd; 

437 

438  OFUN  PVMcopySeg(seid  fromSeid,  toSeid;  segDes  sd);  S(PVMcopySeg) 

439  $(  copies  a  segment  from  the  virtual  memory  "fromSeid"  to  the  virtual 

440  memory  "toSeid";  both  virtual  memories  must  exist;  the  segment 

441  designator  sd  must  exist  in  "fromSeid"  but  not  in  "toSeid";  used  by 

442  the  module  that  sets  up  virtual  memories  for  new  processes) 

443  DEFINITIONS 

444  useStruct  use  IS  SEGuseInfo(f romSeid,  sd); 

445  seid  oldSeid  IS  use. Instance;  InstanceStruct  inst  IS  SEGlnstanceInfo(oldSeid ) ; 

446  seid  newSeld 

447  IS  SENmakeSeid(exampleSegmentSeid, 

448  SOME  INTEGER  i  |  NOT  i  INSET  SEGinUselndexSet ( ) ) ; 
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449  tilStruct  sell  IS  Tllinf o(oldSeld); 

430  tilSeruct  ptll  IS  THlnfo(toSeid) ; 

451  ASSERTIONS 

452  PVMvmExista (f romSeld); 

453  PVMvmExlsts(coSeid); 

454  8d  INSET  PVMsegmentSeC(f romSeld) ; 

455  NOT  sd  INSET  PVMsegmentSet(toSeid) ; 

456  EFFECTS 

457  'SEGinstancelnfo(newSeid)  -  STRUCT ( ins t .gl,  Inst. growth,  1,  Inst. data); 

458  'SEGuseInfo(toSeid,  sd)  -  STRUCT (newSeld,  use.vloc,  use. da); 

459  'Tllinf o(newSeid)  -  STRUCT(stli.nd,  stll.ms,  ptll. owner,  ptll. group, 

460  stil.priv); 

461  'PVMsegmentSet (toSeld)  *  PVMsegmentSet(toSeld)  UNION  {sd}; 

462  sd  INSET  PVMmappedSegmentSet(fromSeld)  “> 

463  'PVMmappedSegmentSet(toSeid )  -  PVMmappedSegmentSet (toSeid)  UNION  {sd}; 

464  ' SEGlnUselndexSet ( ) 

465  -  SEGlnUselndexSet ()  UNION  (SENseldlndex(newSeld)} ; 

466 

467  segment  status  manipulation  «»*»*»**»*»»*•**»«»•**»*) 

468 

469  VFUN  PVMgetSegmentStatus (seld  pSeid,  segSeld;  segDes  segd)  *>  statusStruct  ss; 

470  $(PVMgetSegmentStatus ) 

471  $(  returns  the  status  Information  **  which  Is  much  of  the  global 

472  information  **  for  the  segment;  the  segment  must  exist  In  the  segment 

473  set  of  the  requesting  process) 

474  DEFINITIONS 

475  seld  checkSeld  IS  IF  segd-SEGnullSeg  THEN  segSeld  ELSE 

476  .  SEGuseInfo(pSeld, segd). instance; 

477  segDes  desrefl  IS  SOME  segDes  s| 

478  SEGuselnf o(pSeid ,8 ) . Ins tance-checkSeld ; 

479  segDes  desref  IS  IF  desrefl  -  ?  THEN  SEGnullSeg 

480  ELSE  desrefl; 

481  EXCEPTIONS 

482  XbSgSd:  IF  segd  -  SEGnullSeg  THEN  (SEGinstancelnfo(segSeid)  -  ? 

483  OR  NOT  SMXf low(pSeld,  segSeld,  {daRead})) 

484  ELSE  NOT  segd  INSET  PVMsegmentSet (pSeid) ; 

485  ASSERTIONS 

486  PVMvmExl8ts(pSeld); 

487  DERIVATION 

488  STRUCK 

489 

490 

491 

492 

493 
4*4 

495 

496 

497 

498 

499 

500  ); 

501 

502  0FUN  PVMsetSegmentStatus(seld  pSeid,  segSeld;  globalData  glo); 

503  $(PVMsetSegmentStatus) 

504  $(  changes  the  status  information  for  the  segment;  certain  privileges 


SEGlnstanceInfo(checkSeld).gl, 

SEGlns tancelnf o (checkSeld ) . growth , 

SEGslze(checkSeid), 

checkSeld, 

desref, 

IF  desref "SEGnullSeg  THEN  STRUCT(nullDomaln,nullSpace,0) 

ELSE  SEGuseInfo (pSeid , des  ref ) . vloc , 

IF  des ref "SEGnullSeg  THEN  {} 

ELSE  SEGuselnf o(pSeld, desref ) .da, 

IF  des ref "SEGnullSeg  THEN  FALSE 

ELSE  IF  desref  INSET  PVMmappedSegmentSet (pSeid)  THEN  TRUE 
ELSE  FALSE 
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505  are  required;) 

506  DEFINITIONS 

507  instanceStruct  1  IS  SEGlnsCancelnfo(segSeld); 

508  EXCEPTIONS 

509  XbSgSd :  NOT  (i  "«  ?  AND  SMXf low(pSeld,  segSeid,  {daRead,  daWrlte})); 

510  Xsharable:  i . gl. sharable ; 

511  XswapEh: 

512  glo. swappable  AND  NOT  1 . gl . swappable 

513  AND  NOT  SMXhasPri v(pSeid ,  prlvLockSeg); 

514  XnPvStkSg: 

515  glo. sticky  AND  NOT  i.gl. sticky 

516  AND  NOT  SMXhas Pri v(pSeid ,  pri vStickySeg ) ; 

517  ASSERTIONS 

518  PVMvmExis ts (pSeid ) ; 

519  EFFECTS 

520  'SEGinstancelnf o(segSeid)  »  STRUCT(glo,  i. growth,  i.refCount,  i.data); 

521 

522  $(••••*•••••••*•••••••••••  level  getting  and  setting  »•••••••*  •  miiiimiii ) 

523 

524  VFUN  PVMgetSegmentLevel(seid  pSeid,  segSeid)  *>  tiiStruct  tii; 

525  $(PVMgetSegmentLevel) 

526  EXCEPTIONS 

527  $(LR  "  these  must  be  finalized) 

528  XbSgSd :  NOT  (SEGinstancelnfo(segSeid)  “=  ? 

529  AND  SMXf low(pSeid,  segSeid,  {daRead})); 

530  XbadDa :  NOT  SMXdap(pSeid,  segSeid,  {daRead}); 

531  DERIVATION 

532  Tllinf o(segSeid) ; 

533 

534  OFUN  PVMsetSegmentLevel(seid  pSeid,  segSeid;  tiiStruct  ntii); 

535  $(PVMsetSegmentLevel) 

536  DEFINITIONS 

537  tiiStruct  otii  IS  Tllinfo(segSeid) ; 

538  EXCEPTIONS 

539  XbSgSd:  NOT  (SEGinstancelnf o(segSeid  )  ? 

540  AND  SMXf low(pSeid,  segSeid,  {daRead,  daWrite})); 

541  XbadDa:  NOT  SMXdap(pSeid ,  segSeid,  {daWrite}); 

542  XshSg:  SEGinstanceInfo(segSeid  ).gl. sharable; 

543  XnoSLev:  otii.nd  ”=  ntii.nd 

544  AND  NOT  SMXhas Pri v(pSeid,  prlvLockSeg); 

545  XwOnlSg:  otii. ms  ”=  ntii. ms 

546  AND  ((daWrite  INSET  nt il. ms . owner Mode 

547  AND  NOT  daRead  INSET  ntii. ms . ownerMode ) 

548  OR  (daWrite  INSET  ntii. ms .group Mode 

549  AND  NOT  daRead  INSET  ntii . ms .sroupMode ) 

550  OR  (daWrite  INSET  ntii.ms.allMode 

551  AND  NOT  daRead  INSET  ntii.ms.allMode  )) ; 

552  XchgSgOwn: 

553  (otii. ms  ntii. ms  OR  otii. owner  ntii. owner 

554  OR  otii. group  ntii. group) 

555  AND  otii. owner  Tllinf o(pSeid). owner ; 

556  XnoSPriv:  otii.priv  “»  ntii.priv 

557  AND  NOT  SMXhas Pri v (pSeid,  privModifyPriv) ; 

558  EFFECTS 

559  'Tllinf o(segSeid)  «  ntii; 

560 
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1  $("  MODULE:  pvp. specs  (version  4.12) 

2  CONTENTS:  Virtual  Memory  11  Process  Supp- 

3  TYPE: 

4  LAST  CHANGED:  12/23/80,  16:59:00 

5  ") 

6 

7 

8  MODULE  pvp 

9 

10  $(  this  module  contains  operations  that  support  the  process  module's  use  of 

11  the  virtual  memory  mechanism.  This  is  entirely  a  procedure  abstraction. 

12  It  is  specified  in  terms  of  V*functions  of  other  modules,  but  is 

13  implemented  by  a  program  in  terms  of  operations  of  other  modules. 

14  This  sequence  will  be  included  in  the  comments  for  each  of  the  operations. 

15  This  module  has  no  state  of  its  own  except  for  parameters  for  immediate 

1 6  segments  . ) 

17 

18  TYPES 

19 

20  $(frora  mac) 

21  vAddrType:  {0  ..  MACmaxVAddr } ; 

22 

23  $ ( f  rom  s  mx ) 

24  nonDisType:  STRUCT_0F( 

25  INTEGER  securityLevel ;  SET_0F  securityCat  securityCatS ; 

26  INTEGER  integrityLevel ;  SET_0F  integrityCat  integrityCatS) ; 

27  daTvpe:  SET_OF  daMode ; 

28  modeStruct:  STRUCT_OF(daType  ownerMode,  groupMode,  allMode); 

29  tiiStruct:  STRUCT_0F (nonDisType  nd; 

30  modeStruct  ms;  INTEGER  owner,  group;  SET_0F  privType  priv); 

31 

32  $(from  pvm) 

33  virtualLocation : 

34  STRUCT j0F(domalnType  domain;  spaceType  idSpace;  vAddrType  vAddr); 

35  globalData: 

36  STRUCT_0F( BOOLEAN  sharable,  swappable,  sticky,  memAdvise,  executable; 

37  direction  growth); 

38  instanceStruct : 

39  STRUCT_OF(globalData  gl;  direction  growth;  INTEGER  refCount;  VECT0R_0F  INTEGER  data); 

40  useStruct:  STRUCT_OF(seid  instance;  virtualLocation  vloc;  daType  da); 

41 

42 

43  PARAMETERS 

44 

45  virtualLocation  PVMimmVloc;  $(location  for  immediate  segment) 

46  segDes  PVMimmDes ;  $(designator  for  immediate  text  segment) 

47  segDes  PVMargDes ;  $(designator  for  argument  segment) 

48  virtualLocation  PVMargVloc;  $(location  for  argument  segment) 


49 

50 

51 

DEFINITIONS 

52 

53 

$(from  seg) 

54  INTEGER  SEGsize(seid  segSeid)  IS  LENGTH(SEGinstanceInfo(segSeid ).data) ; 

55 

56  $(from  pvm) 
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57  INTEGER  nSegs(seld  pSeid) 

58  IS  CARDINALITY {segDes  sd  |  SEGuseInfo(pSeid,  sd)  ?}); 

59 

60  BOOLEAN  PVMvmExists (seid  pSeid)  IS  PVMsegmentSet (pSeid )  “»  ?; 

61 

62  SET__0F  INTEGER  addrRegRange( INTEGER  vAddr,  size;  direction  d)  IS 

63  IF  d  -  if’ 

64  THEN  {vAddr  /  MACmaxOffset  ..  (vAddr  +  size  1  1)  /  MACmaxOf fset } 

65  ELSE  {(vAddr  *  size  +  1)  /  MACmaxOffset  ..  vAddr  /  MACmaxOffset}; 

66  $(  gives  the  range  of  address  registers  used  by  a  segment  as  a  function  of 

67  its  start  address,  size,  and  growth  direction) 

68 

69  SET_0F  INTEGER  addrRegRangeSeg(seid  pSeid;  segDes  s)  IS 

70  LET  useStruct  use  «  SEGuselnf o(pSeid,  s) 

71  IN  addrRegRange(use . vloc • vAddr ,  SEGsize(use. ins tance ) , 

72  SEGins  tance Inf o (use . instance ) . gl . growth ) ; 

73  $(  gives  the  range  of  address  registers  used  by  a  segment  as  a  function  of 

74  the  process  id  and  the  segment  designator) 

75 

76  BOOLEAN  noHole(seid  pSeid;  INTEGER  size;  vi rtualLocat ion  vl;  direction  d; 

77  SETjOF  segDes  ssd)  IS 

78  NOT  addrRegRange(vl. vAddr ,  size,  d)  SUBSET  {0  ..  MACmaxReg} 

79  OR  (EXISTS  segDes  s  |  s  INSET  ssd;  useStruct  use  *  SEGuselnf o (pSeid ,  s) 

80  :  use. vloc. idSpace  »  vl.idSpace 

81  AND  use. vloc. domain  »  vl. domain 

82  AND  addrRegRangeSeg(pSeid,  s) 

83  INTER  addrRegRange (vl. vAddr ,  size,  d)  {}); 

84  $(TRUE  if  a  segment  described  by  size,  vl,  and  direction  will  NOT  fit  into 

85  a  hole  in  the  address  space  designated  by  pSeid  and  ssd;  this  includes 

86  testing  for  virtual  memory  underflow  and  overflow) 

87 

88  EXTERNAL REFS 

89 

90  FROM  mac : 

91  INTEGER  MACmaxVAddr, 

92 

93  FROM  smx: 

94  seid:  DESIGNATOR; 

95  privType:  { 

96 

97 

98 

99 
100 
101 
102 

103 

104 

105 

106 

107 

108  daMode:  (daRead,  daWrite,  daExecute}; 

109  securityCat:  DESIGNATOR; 

110  integrityCat:  DESIGNATOR; 

111  domainType:  {nullDomain,  kernelDomain.supervisorDomain.userDomain} ; 

112  VFUN  SENseidNsp(seid  s)  a>  INTEGER  nsp; 


MACmaxOffset,  MACmaxReg; 


privFileUpdateStatus  , 
privLockSeg, 
privMount , 
privStickySeg, 
privViolSimpSecurity, 
privViolSimpIntegrity, 
privViolDiscr Access , 
privSignal , 
privHalt , 

privViolCompartments , 
privlmmigrate 
}; 


privLink, 
privModifyPriv, 
privSetLevel , 
privSetPath , 
pri vViolStarSecurity, 
pri vViolStar Integrity , 
pri vRealizeExec Permission, 
pri vWalkPTable, 
privKernelCall, 
pri vSet Comm, 


Version  4.4 


-1 16- 


WDL-TR7932 


pvp. specs 


Page  3  Wed  Mar  18  11:13:35  1981 


113  VFUN  TIIinfo(seid  anySeid)  *>  tllStruct  CilSt; 

114  VFUN  SMXf low(seid  pSeid,  oSeld;  daType  d)  *>  BOOLEAN  b; 

115  VFUN  SMXdap(seid  pSeid,  oSeid;  daType  d)  »>  BOOLEAN  b; 

116  VFUN  S£NseidIndex(seid  anySeid)  *>  INTEGER  index; 

117 

118  FROM  pvm: 

119  segDes:  DESIGNATOR; 

120  spaceType:  {nullSpace , ISpace ,  dSpace}; 

121  direction:  {up,  down}; 

122  seid  examp leSegmentSeid ;  $(used  for  segment  creation) 

123  INTEGER  PVMmaxSegDes ; 

124  VFUN  SEGinstanceInfo(seid  segSeid)  *>  instanceStruct  is; 

125  VFUN  SEGuseInfo(seid  pSeid;  segDes  segd)  *>  useStruct  us; 

126  VFUN  PVMsegmentSet (seid  pSeid)  *>  SET_0F  segDes  segSet; 

127  VFUN  PVMmappedSegmentSet(seid  pSeid)  *>  SET_0F  segDes  mappedSet; 

128  VFUN  SEGinUselndexSetO  *>  SET_0F  INTEGER  si; 

129 

130 

131  ASSERTIONS 

132 

133  PVMlramVloc. domain  »  supervisorDomain; 

134  PVMimmVloc • idSpace  =  iSpace; 

135  PVMargVloc . domain  «■  supervisorDomain; 

136  PVMargVloc . idSpace  =  dSpace; 

137  $(  constraints  on  parameters) 

138 

139 

140  FUNCTIONS 

141 

142  support  for  PSTreleaseProcess  »•»**'***»*»<»•*») 

143 

144  OFUN  PVPreleaseProcessSupport (seid  pSeid); 

145  $(  This  function  supports  PROreleaseProcess  by  deleting  all  segments  in 

146  the  virtual  memory  named  by  "pSeid"  and  then  deleting  the  virtual  memory 

147  itself) 

148  DEFINITIONS 

149  seid  segSeid (segDes  sd)  IS  SEGuseInfo(pSeid,  sd). instance; 

150  instanceStruct  inst (segDes  sd)  IS  SEGinstanceInfo(segSeid(sd ) ) ; 

131  ASSERTIONS 

152  PVMvmExists(pSeid); 

153  EFFECTS 

154  FORALL  segDes  sd  |  SEGuseInfo(pSeid,  sd)  “**  ? 

155  :  'SEGuseInfo(pSeid,  sd)  *  ? 

156  AND  (IF  inst (sd). ref Count  =  1  AND  inst (sd).gl .sticky  -  FALSE 

157  THEN  'SEGinstancelnf o (segSeid (sd ))  -  ? 

158  AND  'TI I info (segSeid (sd  ) )  -  ? 

159  ELSE 

160  'SEGinstancelnf o(segSeid (sd ) ) 

161  »  STRUCT(inst(sd).gl,  ins t(sd). growth, 

162  ins t(sd). ref Count  *  1 ,  ins t(sd). data )) • 

163  'PVMsegmentSet(pSeid)  •  ?; 

164  'PVMmappedSegmentSet (pSeid)  *  ?; 

165 

166 

167  $(  NOTE  **  There  are  two  special  segments  that  are  appropriate  to  the  invoke 

168  and  spawn  operations:  the  argument  segment  "arg",  already  in  the  virtual 
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169  memory,  which  contains  the  data  to  be  used  by  the  Initialized  process; 

170  and  the  Immediate  segment,  "iaInSeidl,,  which  contains  the  code  for  the 

171  process  Jl  this  code  is  also  called  the  process  boots  trapper ) 

172 

173  support  for  PSTinvoke  ********  *  **  '***  **  '**'*•*  **  ) 

174 

175  OFUN  PVPinvokeSupport (seld  pSeid,  ImmSeld;  segDes  arg);  § (PVPinvokeSupport ) 

176  $(  This  function  sets  up  the  virtual  memory  of  a  process  for 

177  Invocation;  the  new  mapped  set  contains  all  previously  mapped  supervisor 

178  segments  and  the  argument  and  immediate  segments;  the  argument  segment 

179  is  mapped  to  a  different  virtual  location,  and  a  use  is  created  for  the 

180  the  immediate  segment) 

181  DEFINITIONS 

182  InstanceStruct  immlnst  IS  SEGins tancelnf o( immSeid  ) ; 

183  useStruct  argUse  IS  S£GuseInfo(pSeid,  arg); 

184  seid  argSeid  IS  argUse . ins tance ; 

185  InstanceStruct  arglnst  IS  SEGinstanceInfo(argSeid ) ; 

186  EXCEPTIONS 

187  XbSgDes:  argUse  -  ?; 

188  XshrSg:  arglnst .gl. sharable ; 

189  XbSgSd :  NOT  (Inmlnst  ? 

190  AND  SMXflow( pSeid, 

191  XsgNoAcc:  NOT  SMXdapfpSeld ,  lranSeid, 

192  XbSgRng: 

193  NOT  addrRegRange(PVMargVloc.vAddr , 

194  SUBSET  {0  ..  MACmaxReg}; 

195  XbSgRng: 

196  NOT  addrRegRange(PVMimmVloc. vAddr , 

197  SUBSET  {0  ..  MACmaxReg}; 

198  XpostEh: 

199  nSegs(pSeid)  >-  PVMmaxSegDes ; 

200  ASSERTIONS 

201  PVMvmExists (pSeid) ; 

202  EFFECTS 

203  'SEGuselnfofpSeld,  PVMargDes ) 

204  »  STRUCT (argUse. instance ,  PVMargVloc,  argUse. da); 

205  $(  create  a  reference  to  the  immediate  segment) 

206  'SEGuselnfofpSeid,  PVMimmDes ) 

207  »  STRUCT(iramSeid,  PVMimraVloc ,  {daRead,  daExecute}); 

208  'SEGinstancelnfo(immSeid) 

209  *  STRUCT(immIns t . gl ,  immlnst. growth, 

210  immlnst . ref Count  +  1,  immlns t . da ta ) ; 

211  $(  add  the  immediate  segment  to  the  address  space) 

212  'PVMsegmentSet (pSeid)  *  PVMsegmentSet (pSeid  )  UNION  {PVMinmDes .PVMargDes } ; 

213  $(  unmap  all  segments  except  the  argument  segment, 

214  and  the  immediate  segment) 

215  'PVMmappedSegmentSet(pSeid) 

216  *  {PVMargDes,  PVMimmDes}; 

217  $(  remap  the  argument  segment) 

218 

219  $(  •  *  • * •  •*•  •••••  *  'inii  i  'support  for  PSTspawn  *******'*****  •  *  iiuiHunmi ) 

220 

221  OFUN  PVPspawnSupport(seid  parent,  child;  seid  immSeid;  segDes  arg); 

222  S(PVPspawnSupport) 

223  $(creates  a  new  address  space  named  by  child  and  inserts  into  it  two 

224  segment  uses  11  the  argument  segment,  arg,  which  is  copied  from  the  parent 


immSeid,  {daRead})); 

{daExecute } ) ; 

SEGsize( argSeid  ) ,  arglnst .gl. growth) 
SEGsize( immSeid),  immlns t . gl. growth ) 
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225  address  space,  but  occupies  a  different  position  11  PVMargDes  11 

226  and  the  immediate  segment,  immSeid,  which  is  shared) 

227  DEFINITIONS 

228  ins tanceStruct  immlnst  IS  SEGins tancelnfo (immSeid  ) ; 

229  useStruct  argUse  IS  SEGuselnf o(parent ,  arg); 

230  seid  argSeid  IS  argUse. instance ; 

231  ins tanceStruct  arglnst  IS  SEGinstancelnfo(argSeid) ; 

232  seid  argCopy 

233  IS  SOME  seid  s  |  SENseidNsp(s )  =  SENseidNsp(exampleSegmentSeid ) 

234  AND  SEGins tancelnf o(s )  =  ?; 

235  tiiStruct  aTii  IS  Tllinfo(argSeid); 

236  tiiStruct  pTii  IS  Tllinf o(parent ); 

237  tiiStruct  nTii  IS  STRUCT(aTii. nd,  aTii. ms,  pTii. owner,  pTii. group, 

238  aTii.priv); 

239  EXCEPTIONS 

240  XbSgSd:  NOT  (immlnst  ~=»  ?  AND  SMXf low(parent , immSeid , {daRead} )) ; 

241  XsgNoAcc:  NOT  SMXdap (parent ,  immSeid,  {daExecute } ) ; 

242  XshrSg:  arglnst . gl . sharable ; 

243  XnWrtArgSg:  NOT  daWrite  INSET  argUse. da; 

244  XbSgRng : 

245  NOT  addrRegRange(PVMargVloc.vAddr,  SEGs ize(argSeid) ,  arglnst. gl. growth) 

246  SUBSET  {0  ..  MACmaxReg}; 

247  XbSgRng: 

248  NOT  addrRegRange(PVMiramVIoe. vAddr ,  SEGsize( immSeid ) ,  immlnst . gl. growth ) 

249  SUBSET  {0  ..  MACmaxReg}; 

250  RES0URCEERR0R ; 

251  ASSERTIONS 

252  PVMvmExis ts (parent ) ; 

253  NOT  PVMvmExis ts (chi Id); 

254  EFFECTS 

255  $ (  create  a  copy  of  the  argument  segment) 

256  'Tllinf o(argCopv)  =*  nTii; 

257  'SEGinstancelnfo(argCopy)  =  STRUCT (arg Ins t . gl ,  arglnst . growth , 1 , 

258  arglnst .data) ; 

259  'SEGuseInfo(chi Id ,  PVMargDes)  »  STRUCT (argCopy ,  argUse. vloc,  argUse. da); 

260  $(  create  a  use  for  immSeid  in  child) 

261  'SEGuselnf o(chi Id,  PVMiramDes ) 

262  =  STRUCT (immSeid,  f^MimmVloc,  {daRead,  daExecute}); 

263  ' SEGinstancelnf o(immSeid) 

264  =  STRUCT (immlnst .gl, immlnst. growth , immlnst. refCount  +  1,  immlnst .data ) ; 

265  'PVMsegmentSet (child )  =  {PVMiramDes,  PVMargDes}; 

266  'PVMmappedSegmentSet (chi Id )  *■  {PVMimmDes,  PVMargDes}; 

267 

268  5(|»",‘'<niiiiiiiiii  suppcrt  for  PROfork 

269 

270  0FUN  PVPf orkSupport (seid  parent,  child);  $(PVPforkSupport ) 

271  $(creates  a  new  virtual  memory,  child,  that  is  a  copy  of  parent;  some 

272  segments  are  copied  and  others  are  merely  shared;  if  a  segment  is 

273  sharable  in  the  parent  process,  it  is  not  copied,  but  a  use  corresponding 

274  to  the  instance  in  parent  is  created  instead;  if  the  segment  is  not 

275  sharable,  then  a  new  instance  of  the  segment  is  created,  requiring  the 

276  allocation  of  an  unused  seid;  in  either  case,  corresponding  segments  have 

277  identical  segment  designators  in  both  processes;  much  mechanism  in  this 

278  specification  is  devoted  to  describing  the  set  of  new  seids  created  and 

279  the  mapping  of  this  set  onto  Che  set  of  new  segment  instances) 

280  DEFINITIONS 
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281 

282 

283 

284 

285 

286 

287 

288 

289 

290 

291 

292 

293 

294 

295 

296 

297 

298 

299 

300 

301 

302 

303 

304 

305 

306 

307 

308 

309 

310 

311 

312 

313 

314 

315 

316 

317 

318 

319 

320 

321 

322 

323 

324 

325 

326 


INTEGER  nCoples 
IS  CARDINALITY 


( {segDes  sd  I  SEGinstanceInfo(SEGuseInfo(parent, 

sd). Instance ). gl . sharable 


-  FALSE}); 

$(number  of  nonsharable  segments  In  parent  process) 

SET_0F  INTEGER  indexCopySet 
IS  SOME  SET_0F  INTEGER  si 

|  CARDINALITY(si)  -  nCoples  AND  si  INTER  SEGinUse IndexSet ( )  -  {}; 


SETOF  seld  copySet 

IS  {seld  s  |  SENseidNsp(s )  =*  SENseldNsp(exampleSegmentSeid ) 
AND  SENseidIndex(s )  INSET  IndexCopySet}; 

$(actual  set  of  new  seids) 

useStruct  use(segDes  segd)  IS  SEGuselnf o(parent ,  segd); 
instanceStruct  inst(segDes  segd) 

IS  SEGinstanceInfo(use (segd )• instance ) ; 


EXCEPTIONS 

RES0URCEERR0R; 

ASSERTIONS 


PVMvmExls  ts (parent ) ; 

NOT  PVMvmExls ts (child); 
EFFECTS 


'PVMsegmentSet(chlld)  =  PVMsegmentSet (parent ) ; 

'PVMmappedSegmentSet (child )  =  PVMmappedSegmentSet (parent ) ; 

FORALL  segDes  segd  I  SEGuseInfo(parent ,  segd ). instance  ~=  ? 

:  (IF  Inst (segd ).gl. sharable 
THEN 

' SEGus e Inf o( child,  segd)  =*  use(segd) 

AND  'SEGinstanceInfo(use(segd). instance)  * 

STRUCT( Ins t (segd ) . gl ,  inst(segd). growth , 

Inst (segd) .ref Count  +  1,  ins t (se gd ). data) 

ELSE 

(LET  seld  copy  INSET  copySet 

IN  'Tllinf o(copy)  =  Tllinf o(use(segd ). instance ' 

AND  'SEGinstancelnfo(copy)  » 

STRUCT (ins t (segd ).gl,  Inst (segd ). growth , 

1,  inst(segd  ).data) 

AND  'SEGuseInfo(child,  segd)  » 

STRUCT(copy,  use(segd  ). vloc ,  use(segd).da) 

AND  (FORALL  segDes  segdl  segd 

:  ' SEGus elnfo (child ,  segd 1). instance 

'SEGuseInfo(child,  segd). instance))); 

'  SEGinUse ’’idexSetQ  ■  SEGinUselndexSet  ()UNI0N  indexCopySet; 


END  MODULE 
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1  $("  MODULE:  smx. specs  (version  4.14) 

2  CONTENTS:  Security  Model 

3  TYPE:  SPECIAL. specif ications 

4  LAST  CHANGED:  12/23/80,  17:40:14 

5  ") 

6 

7 

8  MODULE  smx 

9 
10 

11  $(  This  module  now  includes  what  used  to  be  the  contents  of  smx,  prv,  tii, 

12  syl,  and  sen  modules) 

13 


TYPES 

$(from  smx  "  exportable) 
seid:  DESIGNATOR; 

secureEntityType :  {tFile,  tDevice,  tTerminal,  tProcess ,  tSegment ,  tSubtype, 
tExtent ,  tNullj; 

privType:  { 

pri vFileUpdateStatus ,  privLink, 
privLockSeg,  pri vModifyPri v, 

privMount,  privSetLevel , 

privStickySeg ,  privSetPath, 

pri vViolSimpSecurity ,  privViolStar Security , 
privViolSimpIntegrity,  privViolStar Integrity , 
pri vViolDiscr Access ,  privRealizeExecPermlssion , 
privSignal,  privWalkPTable , 

privHalt,  privKernelCall, 

privVlolCompactments ,  privSetComm, 
privlmmigrate 
}; 

daMode :  {daRead,  daWrite,  daExecute}; 
securityCat:  DESIGNATOR; 
integrityCat:  DESIGNATOR; 

domainType :  {nullDomain,  kernelDomain,supervisorDomain,userDomain} ; 

$(froo  scax  *'  redeclarable) 
nonDisType:  STRUCT_0F( 

INTEGER  securityLevel ;  SET_0F  securityCat  securityCatS ; 

INTEGER  integrityLevel ;  SET_0F  integrityCat  integrityCatS) ; 
$(integrityCat  is  typically  the  null  set) 
daType:  SET_0F  daMode; 

modeStruct:  STRUCT_0F (daType  ownerMode,  groupMode ,  allMode); 
tiiStruct:  STRUCT_OF(nonDisType  nd ; 

modeStruct  ms;  INTEGER  owner,  group;  SET_0F  privType  priv); 


PARAMETERS 


INTEGER  SENmaxIndex  $(maxiraum  index  component  of  a  seid,  2*24  1  1), 
SENmaxNsp  $(maximura  nsp  component  of  a  seid,  2*8  4  1); 
INTEGER  SENlowLevel,  $(system  low  level) 

SENhighLevel;  $(systera  high  level) 
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57 

58  ASSERTIONS 

59 

60  FORALL  seld  si;  setd  s2:  (si  -  s2)  -  (SENseidNsp(s 1 )  -  SENseldNsp(s2) 

61  AND  SENseidlndex(sl)  -  SENseidIndex(s2)) ; 

62  $(this  states  that  the  nsp  and  index  are  Isomorphic  with  the  seid,  and 

63  thus  uniquely  identify  it) 

64 

65  SENlowLevel  <  SENhighLe vel ; 

66  $(defines  the  "greater  than"  relation  for  security  in  terms  of  the  integer 

67  relation  ">") 

68 

69  SYLgetHighQ  INSET  {8ENlowLevel  ..  SENhighLevel}; 

70  $(the  current  system  high  level  is  alwavs  within  range) 

71 

72  FORALL  seid  s  |  Tllinfo(s)  ? 

73  :  LET  nonDisType  ndl  =  Tllinf o(s ).nd 

74  IN  ndl.securityLevel  INSET  {SENlowLevel  ..  SENhighLevel} 

75  AND  ndl. integrityLevel  INSET  {SENlowLevel  ..  SENhighLevel}; 

76  $(restricts  the  values  of  the  security  and  integrity  levels  for  any 

77  existing  objects) 

78 

79 

80  FUNCTIONS 

81 

82  $(*J  ii  sen  «•  state  functions  uiuiiimiiiiimiuminu) 

83 

84  VFUN  SENseidNspCseid  anySeid)  *>  INTEGER  asp;  $(SENseidNsp) 

85  $(  this  is  the  nsp  table  entry  component  of  a  seid) 

86  INITIALLY 

87  nsp  INSET  {0  ..  SENmaxNsp};  $(constrained  by  assertion  above) 

88 

89  VFUN  SENseidlndexCseid  anySeid)  •>  INTEGER  index;  S(SENseidlndex) 

90  $(  this  is  the  index  component  for  a  seid) 

91  INITIALLY 

92  index  INSET  {0  ..  SENraaxIndex} ; 

93  S(also  characterized  by  assertion) 

94 

95  VFUN  SENns pType ( INTEGER  nsp)  J>  secureEntityType  set;  $(SENnspType ) 

96  $(  gives  the  type  information  as  a  function  of  the  nsp  component  of 

97  a  seid) 

98  INITIALLY  NOT  nsp  INSET  {0  ..  SENmaxNsp}  ->  set  -  ?; 

99 

100  $(******»»*»»**•****  sen  11  seid  and  nsp  manipulation  **»»"»*»»*»*»»■»*****) 

101 

102  VFUN  SENseidToInt (seid  anySeid)  J>  INTEGER  i;  $(SENseidToInt ) 

103  $(gives  the  integer  corresponding  to  a  given  seid) 

104  DERIVATION 

105  SENseidlndex(anySeid)  +  2“24  *  SENseidNsp(anySeid) ; 

106 

107  VFUN  SENseidType(seid  s)  *>  secureEntityType  set;  $(SENseidType) 

108  $(  returns  the  type  information  pertaining  to  a  given  seid) 

109  DERIVATION 

110  LET  secureEntityType  setl  •  SENnspType(SENseidNsp(s ) ) 

111  IN  IF  setl  -  ?  THEN  tNull  ELSE  setl; 

112 
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VFUN  SENmakeSeid(seid  exampleSeid;  INTEGER  index)  J>  seid  rSeid; 

$(SENmakeSeid) 

$(  forms  a  seld  with  an  nsp  Che  same  as  the  example  seid  and  the  given 
index;  seid  allocation  is  now  done  by  the  type  managers  for  the 
objects  In  question,  allowing  seids  to  be  reused  in  the  case  of 
objects  that  are  dynamically  allocated) 

ASSERTIONS 

index  INSET  {0  ..  SENmaxIndex} ; 

DERIVATION 

SOME  seid  s  |  SENseidNsp(s )  =  SENseldNsp(exampleSeid ) 

AND  SENseidIndex(s )  **  index; 

syl  functions  *****  •*  i*»»*»*»  *i  •nniiimniii  t  mi  ) 

VFUN  SYLgetHighO  *>  INTEGER  level;  $(SYLgetHigh) 

$(  represents  the  current  highest  security  level  for  the  system) 

HIDDEN; 

INITIALLY 

level  *  SENhighLevel ; 

OFUN  SYLsetHigh( INTEGER  level);  $(SYLsetHigh) 

$(  sets  the  current  highest  security  level  for  the  system  to  the  specified 
value) 

EXCEPTIONS 

XbSysLev:  NOT  level  INSET  {SENlowLevel  ..  SENhighLevel}; 

EFFECTS 

'SYLgetHighO  =  level; 

til  state  function  ••hiiihuiiiiiiiiiiiiiiiiiiiiiiii) 

VFUN  TIIinfo(seid  s)  *>  tiiStruct  St;  $(TIIinfo) 

$(retums  the  type* independent  information  for  a  system  object;  this 

information  includes  discretionary,  non*discretionary ,  and  domain  access 
controls,  privileges,  and  the  owner  and  group  for  the  object) 

HIDDEN; 

INITIALLY  st  -  ?; 


•• ■  ■  i  ii <i< i tii ii  1 i  •  gmx  functions  <<111111111111111111111111111111111111) 

VFUN  SMXhasPriv(seid  pSeid;  privType  privl)  J>  BOOLEAN  b;  $(SMXhasPriv) 

$(  tells  whether  a  given  object  **  usually  a  process  "  has  a  particular 
privilege) 

DERIVATION 

IF  Tllinfo (pSeid )  ?  THEN  privl  INSET  Tllinf o(pSeid). priv  ELSE  FALSE; 

VFUN  SMXcompare (seid  lSeid,  hSeid)  *>  BOOLEAN  b;  $ (SMXcompare ) 

$(  Primitive  comparison  telling  whether  lSeid  O  hSeid.  No  privileges 
are  accounted  for.) 

DEFINITIONS 

tiiStruct  ITii  IS  Tllinf o(lSeid) ; 
tiiStruct  hTil  IS  Tllinfo(hSeid) ; 

DERIVATION 

IF  ITii  -«  ?  AND  hTii  ? 

THEN  ITii.nd.securityLevel  <■  hTii . nd. securityLevel 
AND  lTli.nd.securityCatS  SUBSET  hTii.nd.securityCatS 
AND  ITii.nd. integrityLevel  >*  hTii.nd. integrityLevel 
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169 

AND  hTii. nd . IntegrityCatS  SUBSET  lTli .nd. IntegrityCacS 

170 

ELSE  FALSE; 

f. 

171 

f 

172 

VFUN  SMXcompWprlv(seid  lSeid.hSeid;  BOOLEAN  privl,prlv2)  *> BOOLEAN  b; 

173 

$(SMXcompWpri v) 

174 

$(Primitive  comparison  telling  whether  lSeid  <»  hSeld,  but 

175 

with  privileges  taken  into  account.  See  SMXflow  comments  re. 

176 

need  for  both  SMXcompare  and  SMXcompWpriv. ) 

177 

DEFINITIONS 

*  i 

178 

tiiStruct  ITii  IS  Tllinfo(lSeid); 

t 

179 

tiiStruct  hTii  IS  Tllinfo(hSeid); 

180 

DERIVATION 

181 

IF  ITii  ?  AND  hTii  ? 

182 

THEN  (privl 

183 

OR 

184 

(  ITii.nd.securityLevel  <■  hTii. nd. securityLevel 

■ 

185 

AND  ITii.nd.securityCatS  SUBSET  hTii.nd.securityCatS 

186 

) 

187 

) 

188 

189 

AND 

190 

191 

(priv2 

192 

OR 

i 

193 

(  ITii.nd. integrityLevel  >=  hTii.nd. integrityLevel 

- 

194 

AND  hTii.nd. IntegrityCatS  SUBSET  ITii . nd . IntegrityCatS 

195 

) 

196 

) 

197 

ELSE  FALSE; 

198 

199 

VFUN  SMXflow(seid  pSeid,  oSeid;  daType  d)  *>  BOOLEAN  b;  $(SMXflow) 

200 

$(  tells  whether  a  given  subject  "pSeid"  can  access  a  given  object  "oSeid" 

■ 

201 

with  the  information  flow  specified  by  "flow",  according  to  the 

, 

202 

constraints  of  the  military  multilevel  security  model;  these  constraints 

203 

do  not  apply  if  the  subject  has  the  proper  privilege) 

204 

$("  The  reason  for  having  both  SMXcompare  and  SMXcompWpriv  is  that 

* . 

205 

the  MLS  tools  have  axiomatized  SMXcompare,  i.e.,  do  not  account 

206 

for  privileges;  the  implementation  does  account  for  privileges. 

-  • 

207 

The  following  relationships  are  true: 

1 

208 

FORALL  seid  s 1 ,s2 |TIIinfo(s 1 )"-?  AND  TIIinfo(s2)~-?  : 

k 

209 

SMXcompWpriv (s 1 , s  2 , TRUE , TRUE )  -  TRUE 

210 

AND  SMXcompWpriv  (s 1 , s2, FALSE , FALSE )  ■  SMXcompare (s l,s2) 

|* 

211 

AND  SMXcompare (sl,s 2)  =■>  SMXcompWpriv(s  1  ,s2, TRUE, FALSE) 

212 

AND  SMXcompare (s 1 ,s2)  ■>  SMXcompWpriv (s 1 ,s 2, FALSE , TRUE) ; 

213 

") 

214 

DERIVATION 

^  . 

215 

(daWrite  INSET  1  -> 

- 

216 

SMXcompare (pSeid,  oSeid) 

'  1 

217 

OR 

218 

SMXcompWpriv (pSeid, oSeid, SMXhasPri v(pSeid,privViolStarSecurity ) , 

,  i 

219 

SMXha8Priv(pSeid,privViolSimpIntegrity) ) 

220 

) 

221 

AND 

222 

(daRead  INSET  d  «> 

223 

SMXcompare (oSeid ,  pSeid) 

224 

OR 

.  » 


Version  4.4 


-124- 


WDI.-TR7932 


smx. 

225 

226 

227 

228 

229 

230 

231 

232 

233 

234 

235 

236 

237 

238 

239 

240 

241 

242 

243 

244 

245 

246 

247 

248 

249 

250 

251 

252 

253 

254 

255 

256 

257 

258 

259 

260 
261 
262 

263 

264 

265 

266 

267 

268 

269 

270 

271 

272 

273 

274 

275 

276 

277 

278 

279 

280 


specs  Page  5  Wed  Mar  18  11:13:50  1981 

SMXcompWpriv(oSeid,pSeid,SMXhasPriv(pSetd,privViolSimpIntegrity) , 
SMXhasPriv(pSeid,privViolStarIntegricy) ) 


VFUN  SMXdap(seld  pSeid,  oSeid;  daType  d)  J>  BOOLEAN  b;  $(SMXdap) 

$(  Cells  whether  a  given  subject  "pSeid"  can  access  a  particular  object 
"oSeid"  according  to  the  discretionary  access  rules  of  the  system  ** 
similar  to  those  of  UNIX) 

DEFINITIONS 

tiiStruct  p  IS  Tllinf o(pSeid ) ; 
modeStruct  mst  IS  Tllinf o(oSeid) .ms ; 
tiiStruct  o  IS  Tllinfo(oSeid) ; 

BOOLEAN  access (daType  requested,  allowed) 

IS  requested 

SUBSET  allowed 

UNION  (IF  SMXhasPriv(pSeid,  pri vRealizeExecPermission) 
AND  daExecute  INSET  allowed 
THEN  {daRead} 

ELSE  {}); 

DERIVATION 
IF  o  ~=  ? 

THEN  SMXhasPriv(pSeid,  privViolDiscrAccess ) 

OR  access (d,  mst . allMode ) 

OR  (p. group  -  o. group  AND  access (d,  mst .groupMode)) 

OR  (p. owner  »  o. owner  AND  access(d,  ms C . owne rMode ) ) 

ELSE  FALSE; 


^liiuniiinii  tii  n  extraction  and  insertion  functions**  *******  ****** ) 

OFUN  TIIcreateEntityLevel(seid  oSeid;  tiiStruct  nti i) ; $(TIIcreateEntityLevel ) 
$(  Initializes  the  til  information  for  an  object  "oSeid";  the  object  must 
not  have  currently  defined  tii  information;  this  is  a  service  function 
required  for  the  creation  of  all  types  of  objects  in  KSOS) 

ASSERTIONS 

Tllinfo (oSeid)  »  ?; 

ntii.nd.securityLevel  INSET  {SENlowLevel  ..  SYLgetHigh( ) } ; 
ntii .nd. integrityLevel  INSET  {SENlowLevel  ..  SENhighLevel} ; 

EFFECTS 

'TIIinfo(oSeid)  -  ntii; 

VFUN  TIIgetEnc ityLe vel(seid  pSeid,  oSeid)  *>  tiiStruct  ntii; 

$(TIIgetEntityLevel ) 

$(Retrieves  the  tii  information  of  an  object  named  by  "oSeid",  as 

directed  by  process  "pSeid";  mandatory  and  discretionary  checks  are  also 
performed;  this  function  is  used  by 

functions  of  the  object ‘maintaining  modules,  which  provide  status 
information  to  the  object  that  is  concerned  with  getting  and  setting 
object  levels) 

EXCEPTIONS 

XnoObj:  NOT(TIIinf o(oSeid)  ? 

AND  SMXf low(pSeid ,  oSeid,  {daRead})); 

DERIVATION 

Tllinfo(oSeid) ; 

OFUN  TIIsetEntityLevel(seid  pSeid,  oSeid;  tiiStruct  ntii); 
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281  $ (T1 Is  eCEnt i tyLevel ) 

282  $(  sets  the  type4independent  Information  for  an  existing  object 

283  "oSeid"  to  the  new  value  "ntll",  as  directed  by  process 

284  "pSeld";  the  privilege  to  set  level  is  always  required;  if  an 

285  object's  privileges  are  to  be  modified,  the  privilege  to  modify 

286  privileges  is  required;  because  only  privileged  programs  are  allowed  to 

287  invoke  this  function,  no  other  security  checks  **  either  mandatory 

288  or  discretionary  J*  are  made) 

289  DEFINITIONS 

290  tiiStruct  otii  IS  Tllinf o(oSeid) ; 

291  BOOLEAN  sameOwner 

292  IS  Tllinf o(pSeid) . owner  ■  Tllinfo(oSeid). owner 

293  OR  SMXhasPriv(pSeid,  pri vSetLevel ) ; 

294  EXCEPTIONS 

295  $(privilege  checking  occurs  in  lev  module) 

296  XnSPrlv: 

297  otii.priv  ntii.priv  AND  NOT  SMXhasPri v(pSeld,  privModifyPriv); 

298  XnoObj:  otii  -  ? 

299  OR  (otii. ms  ntii.ms  AND  NOT  SMXflow  (pSeid , oSeid ,  {daWrite}) 

300  AND  NOT  sameOwner); 

301  KEtiiNoSetLev: 

302  otii. nd  -»  ntli.nd  AND  NOT  SMXhasPriv(pSeid,privSetLevel ) ; 

303  KEfiiNoSetPriv: 

304  otii.priv  “■  ntii.priv  AND  NOT  SMXhasPriv(pSeid,privSetLevel); 

305  KEtllNoSetOwner: 

306  otii. owner  “■  ntii. owner  AND  NOT  SMXhasPriv(pSeid,privSetLevel)  AND  (pSeid  oSeid 

307  KEtilNoSetGroup : 

308  otii. group  “■  ntll. group  AND  NOT  SMXhasPriv(pSeid.privSetLevel)  AND  (pSeid  “**  oSeid 

309 

310 

311  ASSERTIONS 

312  ntii.nd.securityLevel  INSET  {SENlowLevel  ..  SYLgetHigh( ) } ; 

313  ntli.nd. integrityLevel  INSET  {SENlowLevel  ..  SENhighLevel} ; 

314  EFFECTS 

315  'Tllinf o(oSeid)  -  ntii; 

316 

317  OF  UN  TIIclearEntityLeveKseid  oSeid);  $(TI  IclearEntityLevel ) 

318  $(  deletes  the  type*independent  information  for  an  object  "oSeid";  this 

319  function  is  used  for  implementing  functions  that  delete  objects  ,J  and 

320  thus  must  also  delete  the  tli  info) 

321  EFFECTS 

322  'TIIinfo(oSeid)  -  ?; 

323 

324 

325  END  MODULE 
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1  $("  MODULE:  spf. specs  (version  4.6) 

2  CONTENTS:  Special  Functions 

3  TYPE:  SPECIAL. specif icat ions 

4  LAST  CHANGED:  7/28/80,  09:56:25 

5  "> 

6 

7 

8  MODULE  spf 

9 
10 

11  $(  This  module  will  contain  the  specifications  for  functions  which  do  not 

12  properly  fit  into  any  of  the  other  kernel  modules.  Functions  so  envisioned 

13  will  synchronize  the  file  system,  cause  the  system  to  halt,  and  set  the 

14  maximum  system  security  level.  As  of  now  these  functions  are  left 

15  unspecified) 

16 

17 

18  TYPES 

19 

20  SPFfunctionType :  {syncSPF,  imraSegSPF,  sysHaltSPF,  levelSetSPF} ; 

21  SPFargs :  VECT0R_0F  INTEGER; 

22 

23 

24  EXTERNALREFS 

25 

26  FROM  s  mx : 

27  seid:  DESIGNATOR; 

28 

29 

30  FUNCTIONS 

31 

32  OFUN  SPFspecialFunction(seid  pSeid;  SPFfunctionType  fn;  SPFargs  args); 

33  $(SPFspecialFunction) 

34  $(this  function  will  be  further  specified  when  its  exact  nature  is  known) 

35 

36  END  MODULE 
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Kernelized  Secure  Operating  System  (KSOS) : 

UNIX  Emulator  Computer  Program  Development  Specification  (Type  B5) 


1.  SCOPE 


1*1  Identification 


This  specification  establishes  the  performance,  design,  development  and 
test  requirements  for  the  Kernelized  Secure  Operating  System  (referred  to  as 
"KSOS")  UNIX  Emulator.  The  UNIX  Emulator  is  intended  to  support  the  user  program 
interface  of  the  Western  Electric  UNIX  operating  system  Version  6.0. 

1*2  Functional  Summary 

The  UNIX  Emulator  CPCI  creates  a  system  call  interface  which  is  compatible 
wich  that  provided  by  the  UNIX  operating  system  [Ritchie  74],  [Thompson  75]. 
The  UNIX  Emulator  is  an  operating  system,  running  on  the  "Kernel  Machine",  which 
creates  UNIX  level  resources  from  Che  more  primitive  resources  provided  by  the 
Kernel.  The  hierarchical  UNIX  file  structure  is  created  through  the  cooperation 
between  the  UNIX  Emulator  and  Che  trusted  Directory  Manager.  The  Emulator  also 
concains  the  per  user  aspects  of  support  for  the  interface  to  a  computer  net¬ 
work. 


The  remainder  of  these  specifications  are  organized  aa  follows: 

*  Section  2  contains  the  references 

♦  Section  3  contains  the  requirements  for  the  CPCI 

&  Section  4  contains  the  quality  assurance  provisions  for  the  CPCI 

&  Sections  5  and  6  are  not  applicable  and  are  null. 

These  specifications  serve  two  distinct  purposes.  The  first  is  to  define 
the  UNIX  Emulator  in  a  generic,  machine  independent  way.  The  second  is  to 
define  an  implementation  for  the  PDP-il/70.  Thus,  there  are  many  POP-ll/70 
specific  remarks.  These  should  be  treated  as  non-binding,  informative  commen¬ 
tary  for  non-PDP-1 1 /70  Implementations. 

1*3  Terminology 

The  language  used  throughout  this  specification  attempts  to  conform  to  the 
guidelines  of  Section  3.2.3  of  MIL-STD-490.  In  particular,  the  word  "shall" 
means  that  the  specification  expresses  a  provision  that  is  binding.  The  words 
"should"  and  "may"  mean  that  the  specification  expresses  a  provision  wMch  is 
non-mandatory.  The  word  "will"  is  used  to  express  a  declaration  of  purpose  on 
the  part  of  the  Government. 

KSOS  shall  support  the  mandatory  DoD  security  policy  of  DoD  Directive 
5200. 1-R  that  is  embodied  in  a  Government  approved  mathematical  model.  [Verif 
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78]  Proofs  of  the  system's  security  properties  shall  be  in  terms  of  this  model* 
KSOS  shall  provide  a  minimum  of  elghc  (8)  hierarchical  securicy  classifications 
categories  (or  simply  securicy  categories)  and  a  minimum  of  thirty-two  (32) 
mutually  independent  security  compartments*  The  security  categories  shall  be 
such  that 


UNCLASSIFIED  <  CONFIDENTIAL  <  SECRET  <  TOP  SECRET 


Where  "<"  is  defined  in  accordance  with  the  requirements  of  DoD  5200. 1-R.  One 
security  compartment  shall  be  reserved  for  read  protection  of  system  data  bases 
and  programs*  This  compartment  shall  be  called  the  "system"  compartment.  KSOS 
shall  provide  for  Kernel-enforced  integrity.  Integrity  is  defined  as  Che  formal 
mathematical  dual  of  security  [Biba  75].  At  least  four  (4)  hierarchical 
integrity  classifications  categories  (or  simply  integrity  categories)  shall  be 
provided  in  KSOS.  The  integrity  categories  include  at  least  the  following  three 
classification  categories: 

USER  <  OPERATOR  <  ADMINISTRATOR 

Although  there  is  no  immediate  requirement  for  integrity  compartments,  the 
development  contractor  should  include  provisions  to  ease  their  later  inclusion. 
For  the  remainder  of  this  specif icaticn,  the  term  "security  level"  means  the 
combination  of  a  security  category  and  a  set  of  security  compartments  (which  may 
be  null).  The  term  "integrity  level"  means  the  combination  of  an  integrity 
category,  and  a  (presently  always  null)  set  of  integrity  compartments.  The  term 
"level"  (or  access  level)  means  the  security  and  integrity  level,  that  is,  the 
combination  of  a  security  category,  a  set  of  security  compartments  (which  may  be 
null),  an  integrity  category,  and  a  (presently  always  null)  set  of  integrity 
compartments.  The  "access  matrix"  defines  for  a  particular  user  or  group  the 
combination  of  the  maximum  security  level  permitted  for  that  user  or  group,  all 
security  compartments  to  which  that  user  or  group  has  access,  the  maximum 
integrity  level  for  that  user  or  group,  and  all  integrity  compartments 
(presently  always  null)  to  which  Chat  user  or  group  has  access* 

In  a  secure  system  it  is  necessary  to  have  processes  external  to  the  kernel 
which  perform  security  critical  functions.  These  have  come  to  be  called 
"trusted  processes".  In  KSOS  there  is  a  refinement  in  this  terminology.  As 
Figure  1-1  shows  there  are  subdivisions  of  the  software  inside  the  security  per¬ 
imeter.  Some  of  the  processes  are  "privileged".  This  means  that  they  may 
violate  one  or  more  of  the  security  rules  enforced  by  the  Kernel.  These 
processes  must  be  designed  and  implemented  with  the  same  care  and  thoroughness 
as  Che  Kernel  itself*  A  second  subdivision  has  been  termed  "responsible" 
processes.  These  are  processes  are  not  privileged  to  violate  any  of  the 
Kernel's  rules,  but  which  are  nonetheless  important  to  the  overall  securicy  of 
the  system.  Examples  of  responsible  processes  include  the  Secure  Mail  facility 
and  the  processes  which  manipulate  the  data  bases  describing  the  users'  security 
and  integrity  permissions  (the  "access  matrix").  These  processes  must  also  be 
carefully  designed  and  implemented,  but  do  not  require  formal  specification  of 
verification.  Because  they  do  perform  security-related  functions,  they  cannot 
include  untrusted  components  (e.g.  the  UNIX  Emulator) .  The  third  subdivision  is 
the  "encapsulated  utilities"  (EU  in  the  figure).  These  are  self  contained 
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Emulator  process  part  I 


V  V 


Security  kernel 


Host  (PDP-11/70)  computer 


User  domain 


Supervisor  domain 


Kernel  domain 


Figure  1-1.  Terminology  Figure 

functions  to  which  the  user  simply  supplies  parameters.  The  encapsulated  utili¬ 
ties  are  not  privileged  to  violate  Kernel  rules,  and  do  not  affect  the  security 
of  users.  The  chief  function  in  the  encapsulated  utilities  is  system 
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2.  APPLICABLE  DOCUMENTS 


The  following  documents,  of  exact  issue  shown,  form  a  part  of  this  specifi¬ 
cation  to  Che  extent  specified  herein.  In  the  event  of  a  conflict  between  the 
referenced  documents  and  the  contents  of  this  specification,  this  specification 
shall  be  considered  a  superseding  requirement.  In  the  text  references  to  these 
documents  are  in  the  form  [Name  date],  e.g*  [Biba  75] . 

2. 1  Government  Documents 


2.1.1  Directives.  Manuals  and  Standards 

a.  DoD  5200. 1-R  Information  Security  Program  Regulation 

b.  DoD  5200.28  Security  Requirements  for  Data  Processing  (ADP) 

c.  DoD  5200. 28-M  ADP  Security  Manual 

d.  MIL-STD-483  Conf iguration  Management 

e.  MIL-STD-490  Specification  Practices 

f.  MIL-STD-1 52 1A  Technical  Reviews  and  Audits 


2.1*2  Reports 

a.  [A-Specs  78]  "KSOS  System  Specification  (Type  A)",  WDL-TR7808  Revision  1, 
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3-  REQUIREMENTS 

3* 1  Computer  Program  Definition 

This  CPCI  defines  an  operating  system  program  to  be  Implemented  upon  the 
KSOS  Security  Kernel  which  shall  emulate  the  call  Interface  of  the  Western  Elec¬ 
tric  Corp.  UNIX  operating  system.  The  resulting  operating  system  shall  provide 
a  UNIX  environment  which  enforces  DoD  military  security  policy.  For  additional 
product  specification  Information,  the  reader  Is  referred  to  the  KSOS  System 
Specification  (Type  A)  (A-Specs  78] . 

The  KSOS  UNIX  Emulator  has  two  major  components:  the  operating  syscera  call 
Emulator  and  the  Directory  Manager. 

3.1*1  Interface  Requirements 

The  UNIX  Emulator  shall  execute  in  the  memory  and  privilege  domain  between 
user  programs  and  the  Security  Kernel.  On  the  PDP-11/70,  the  Emulator  shall 
execute  in  the  Supervisor  domain  of  the  machine.  The  Emulator  data  base  shall 
be  protected  from  tampering  by  the  user  process  through  the  virtual  memory 
hardware  of  the  host  computer.  To  the  Security  Kernel,  the  Emulator  and  the 
user  program  are  considered  to  be  one,  untrusted  process  that  simultaneously 
occupies  more  chan  one  virtual  memory  domain. 

The  user  program  shall  be  capable  of  trapping  to  either  the  Emulator  or 
directly  to  the  Security  Kernel.  In  the  PDP-11/70  implementation  of  KSOS,  the 
EMT  Instruction  shall  be  used  to  trap  to  the  Kernel.  The  TRAP  instruction  shall 
cause  a  trap  to  Che  Emulator.  The  Emulator  shall  be  dispatched  to  the  appropri¬ 
ate  trap  handler,  saving  the  state  of  che  user's  registers.  The  PDP-11/70  KSOS 
system  may  allocate  general  register  set  1  to  the  Emulator  and  user  programs. 
General  register  set  0  may  be  used  by  the  Security  Kernel. 

The  relationship  between  the  user  program  and  the  Emulator  may  be  a 
cooperative  one.  Because  the  user  may  execute  Kernel  calls  directly,  it  may  be 
possible  to  circumvent  the  Emulator  and  cause  undesirable  effects.  These 
effects  shall  be  confined  Co  Che  user  process  only  without  disturbing  the 
processes  of  other  system  users  except  as  other  user  processes  have  arranged  and 
expect  to  cooperate  with  the  corrupted  process  (for  example  through  ports  or 
files)  and  to  Che  extent  Chat  the  corrupted  process  deviates  from  its  expected 
behavior.  Although  the  Emulator  data  bases  shall  be  protected  from  direct  mani¬ 
pulation  by  the  user  program,  the  Emulator  may  be  viewed  as  an  extension  of  the 
user  process,  acting  on  the  behalf  of  the  user.  The  user  may  abuse  Che  services 
of  the  Emulator  at  the  peril  of  the  process.  Information  compromises  shall 
never  result  from  erroneous  interaction  of  the  user  process  part  and  the  Emula¬ 
tor. 

3.1.1. 1  Interface  Block  Diagram 

Figure  1*2 is  the  interface  block  diagram  for  the  KSOS  UNIX  Emulator.  This 
diagram  illustrates  the  layers  of  virtual  machine  or  functional  capability  in 
the  KSOS  operating  system.  The  KSOS  UNIX  Emulator  interfaces  directly  with  the 
Security  Kernel  and  user  programs  through  che  interdomain  call  facility  of  the 
PDP-11/70  hardware.  The  PDP-11  EMT  instruction  shall  be  used  for  direct 
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Figure  1-2.  Interface  Diagram 

Emulator  to  Kernel  communication.  The  PDP-11  TRAP  and  IOT  instructions  shall  be 
used  to  emulate  the  UNIX  call  Interface.  Existing  UNIX  software  uses  the  TRAP 
and  IOT  instructions  for  operating  system  calls.  Hence,  compatibility  with 
current  UNIX  shall  be  maintained.  The  UNIX  call  Emulator  spawns  a  directory 
manager  as  needed.  Directory  creation,  deletion  and  update  requests  shall  be 
transfered  through  a  parameter  segment  when  the  Directory  Manager  is  spawned  by 
the  Emulator.  Responses  from  the  Directory  Manager  (i.e.,  error  reports)  shall 
be  sent  by  IPC  message  to  the  Emulatot  of  the  process  which  initiated  the  direc¬ 
tory  operation. 

3. 1.1.2  Detailed  Interface  Definition 
3.1. 1.2.1  Files 

UNIX  files  shall  remain  intact  in  KSOS.  The  user  shall  be  restricted  from 
observing  certain  file  status  information,  i.e.,  link  counts.  These  restric¬ 
tions  shall  be  required  to  remove  clandestine  information  channels  between  users 
of  different  security  and  integrity  levels. 

The  Security  Kernel  shall  support  a  mutual  exclusion  mechanism  on  Kernel 
level  files.  (This  mechanism  may  be  used  to  regulate  updates  on  directories.) 
Future  implementations  of  the  KSOS  Emulator  should  be  able  to  take  advantage  of 
the  open  for  exclusive  use  feature  of  the  Kernel.  When  a  file  is  opened  for 
exclusive  use,  other  processes  attempting  to  open  the  file  for  reading  or  writ¬ 
ing  shall  be  forced  to  block  until  the  file  has  been  closed  or  until  a  system 
default  timeout  has  expired.  Support  of  exclusive  use  files  at  the  KSOS  user 
level  is  beyond  the  scope  of  the  current  Emulator  contract,  but  would  be  a 
rewarding  future  addition  to  the  Emulator. 
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3.1. 1.2.2  Directories 

UNIX  directory  semantics  shall  be  retained  in  their  entirety  in  KSOS.  The 
operation  of  the  UNIX  calls  link,  unlink  and  creat  shall  be  compatible  with 
standard  UNIX  relative  to  directory  semantics.  (However,  the  access  checking  on 
link  and  unlink  shall  be  tightened  in  KSOS.) 

The  integrity  of  the  KSOS  file  systems  should  be  improved  over  the  present 
Version  6.0  UNIX.  Directories  may  be  implemented  using  Che  Kernel  file  subtype 
mechanism,  preventing  casual  manipulation  of  file  directories.  The  Directory 
Manager  shall  provide  a  substantial  demonstration  of  KSOS  file  subtypes.  The 
KSOS  user  shall  be  unaware  of  Che  existence  of  subtypes;  the  Emulator  shall  make 
the  directory  mechanism  transparent  to  the  user  process. 

3.1. 1.2.3  Processes 


Standard  UNIX  process  semantics  shall  also  be  retained.  Due  to  the  media¬ 
tion  of  Che  Kernel,  the  invocation  of  trusted  software  and  core  dumping  shall  be 
secure.  Trusted  software  shall  be  invoked  through  the  Kernel  K_invoke  and 
K_spawn  calls.  Because  core  dumps  shall  be  performed  outside  the  Security  per¬ 
imeter  of  the  Kernel  by  che  Emu'ator,  unauthorized  disclosure  of  information 
shall  be  prevented.  The  Emulator  shall  not  write  a  core  dump  file  without  the 
appropriate  access  capability.  Communication  with  trusted  children  shall  be 
disallowed  by  the  child,  preventing  compromises  through  ptrace  and  other  inter¬ 
process  communication  (IPC)  channels. 

KSOS  users  may  be  capable  of  sharing  data  through  common  process  segments. 
Process  segments  shall  be  manipulated  through  the  direct  user  to  Kernel  inter¬ 
face.  Future  enhancements  to  the  Emulator  should  provide  Emulator  calls  for 
manipulating  segments,  preventing  Emulator  "blind  spots"  and  providing  a  more 
congenial  interface  to  the  user  for  segment  manipulation.  Although  the  user  may 
succeed  in  confusing  the  Emulator  by  changing  process  segments  directly,  no 
compromise  of  information  shall  occur. 

3. 1. 1. 2.4  Pipes 

Version  6.0  pipes  shall  be  implemented  by  the  KSOS  Emulator.  Pipes  may  be 
implemented  using  Kernel-level  shared  segments . 

3. 1*1. 2.5  Ports 


Ports  will  be  a  user  level  mechanism  for  inter-process  communication.  KSOS 
ports  will  be  based  upon  RAND  ports,  augmented  by  two  new  operating  system  calls 
(await  and  capac)  which  provide  low  level  channel  synchronization  [Nemeth  et  al. 
77].  Ports  may  be  implemented  using  shared  segment  communications,  providing 
greater  channel  bandwidth  than  current  implementations.  Further  information  on 
RAND  ports  may  be  found  in  (Sunshine  77]  and  [Zucker  77]. 
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Figure  3-3.  List  of  KSOS  UNIX  Emulator  Calls 
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3. 2  Detailed  Functional  Requirements 

This  paragraph  describes  the  detailed  functional  requirements  of  Che  KSOS 
UNIX  Emulator.  Figure  3-2  summarizes  the  Emulator  calls  by  name  disced  alpha¬ 
betically),  Specification  paragraph  number,  and  system  entry  number.  The  system 
entry  number  corresponds  co  Che  low  order  byte  of  the  FDP-11/70  TRAP  instruction 
used  to  enter  the  Emulator. 

For  each  call,  a  list  of  exception  conditions  is  provided-  The  order  of 
this  list  is  not  necessarily  the  order  in  which  the  conditions  would  be 
evaluated.  The  development  contractor  may  alter  the  order  or  add  to  the  excep¬ 
tion  conditions  as  needed,  subject  to  Government  approval.  Various  exceptions 
detected  during  a  system  call  may  not  recurn  distinct  error  numbers,  but  rather, 
may  maintain  compatibility  with  existing  UNIX  error  numbers. 

3.2.1  abort 


3. 2. I . 1  Inputs 

The  Emulator  call  abort  shall  take  the  following  parameters. 
None 


3.2. 1.2  Processing 

The  Emulator  abort  call  shall  cause  a  core  image  of  the  user-mode  part  of 
Che  process  and  the  system's  per-user  data  for  that  user  to  be  dumped  to  a  disk 
file.  The  core  image  file  shall  not  be  produced  unless  all  the  conditions 
necessary  to  create  a  file  in  the  working  directory  of  the  process  nave  been 
satisfied.  Including  mandatory  security  and  discretionary  access  permissions. 
(These  same  conditions  shall  apply  to  dumps  created  as  a  result  of  some  process 
induced  fault.) 

3.2. 1.3  Outputs 


The  Emulator  call  abort  shall  return  the  following  values  after  execution. 
None  (Does  not  return) 

The  core  file  shall  be  created,  if  possible,  and  the  parent  process  shall  be 
notified  about  the  death  of  this  process. 

3.2.2  await 

3. 2. 2. 1  Inputs 

The  Emulator  call  await  shall  take  the  following  parameters. 

to:  time  out 

wc:  wake  up  conditions 
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3. 2. 2. 2  Processing 

(Not  present  In  Version  6.0  UNIX.)  The  Emulator  call  await  shall  permit  a 
process  to  suspend  its  execution  until  either  a  time  out  event  has  occurred  or 
one  of  the  specified  wake  up  conditions  has  been  met.  The  time  out  value  may  be 
specified  in  1/60  seconds,  or  some  ocher  appropriate  time  unit.  The  minimum  set 
of  wake  up  conditions  to  be  implemented  shall  be: 


a.  wake  up  when  any  pipe  is  written 

b.  wake  up  when  any  pipe  is  read 

c-  wake  up  when  any  pipe  becomes  empty 

If  che  desired  wake  up  event  has  occurred  at  the  time  of  the  await  call,  the 
process  shall  not  block,  but  return  to  the  process  immediately.  The  wake  up 
value  zero  shall  cause  the  process  to  wait  only  on  the  wake  up  conditions. 

3. 2. 2. 3  Outputs 


The  Emulator  call  await  shall  return  Che  following  values  after  execution. 

cw:  wake  up  event  which  caused  process  to  awaken 
ec:  error  conditions 


The  Emulator  call  await  shall  detect  and  report  che  following  exception 
(error)  conditions. 

EX:  invalid  time  out  value 

EX:  invalid  wake  up  condition  specified 


3.2.3  break 
3.2. 3 . 1  Inputs 

The  Emulator  cali  break  shall  cake  the  following  parameters, 
na:  new  break  address 


3. 2. 3. 2  Processing 

The  Emulator  call  break  shall  increase  the  length  of  the  process  data  seg¬ 
ment  to  the  new  break  address.  Break  shall  also  permit  process  data  segments  to 
shrink.  Access  attempts  to  locations  between  the  break  address  and  the  stack 
pointer  shall  cause  a  segmentation  violation  signal  if  access  is  attempted  to  a 
currently  unmapped  portion  of  the  virtual  address  space  (PDP-11/70  peculiarity). 
The  PDP-11 /70  implementation  of  KSOS  shall  express  the  break  address  as  a  multi¬ 
ple  of  512  bytes. 
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3. 2. 3. 3  Outputs 

The  Emulator  call  break  shall  return  the  following  values  after  execution, 
ec:  error  conditions 


The  Emulator  call  break  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  physical  memory  resources  exhausted 

EX:  memory  management  hardware  resources  exhausted 


3.2.4  capac 


3. 2. 4. 1  Inputs 

The  Emulator  call  capac  shall  take  the  following  parameters. 

fd:  file  descriptor  of  pipe  (or  port) 

cv:  pointer  to  two  integer  vector  for  byte  counts 


3.2. 4. 2  Processing 

(Not  present  in  Version  6.0  UNIX.)  (This  call  subsumes  the  RAND  empty  call 
[Sunshine  77]  and  [ZucKer  77].)  The  capac  Emulator  call  shall  return  the  number 
of  bytes  in  a  pipe  (or  port"*  avallsti).*  for  reading  and  writing.  This  call  shall 
not  cause  the  process  to  block. 

3. 2. 4. 3  Outputs 

The  Emulator  call  capac  shall  return  the  following  values  after  execution. 

br:  number  of  bytes  available  for  reading 
bw:  number  of  bytes  available  for  writing 


The  Emulator  call  capac  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  invalid  file  descriptor 

EX;  file  descriptor  does  not  refer  to  pipe  (or  port) 

EX:  Improper  vector  pointer  address 


3.2.5  ch  dir 
3. 2 . 5. I  Inputs 

The  Emulator  call  chdir  shall  take  the  following  parameters. 
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pn:  pathname  of  directory  file 

3. 2. 5. 2  Processing 

The  Emulator  call  chdir  shall  change  the  current  process  working  directory 
to  the  specified  directory. 

3. 2. 5. 3  Outputs 

The  Emulator  call  chdir  shall  return  the  following  values  after  execution, 
ec:  error  conditions 


The  Emulator  call  chdir  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  directory  required  to  interpret  pathname  is  unmounted 
EX:  file  on  name  interpretation  path  is  not  a  directory 
EX:  directory  on  name  interpretation  path  does  not  exist 
EX:  directory  on  name  interpretation  path  has  Search  permission  denied 
EX:  directory  required  for  name  interpretation  has  higher  security  level 
(returned  as  if  directory  did  not  exist) 

EX:  directory  on  name  interpretation  path  is  at  lower  integrity  level 
(returned  as  if  directory  did  not  exist) 

3.2.6  chmod 
3. 2. 6.1  Inputs 

The  Emulator  call  chmod  shall  take  the  following  parameters. 

pn:  pointer  to  file  pathname 
da:  new  discretionary  access  mode 


3. 2. 6. 2  Processing 

The  chmod  call  shall  change  the  discretionary  access  mode  of  a  file.  Only 
the  file  owner  and  sufficiently  privileged  processes  may  change  the  discretion¬ 
ary  access  mode  of  a  file.  Because  the  chmod  call  is  partially  processed  by  the 
uncrusted  Emulator,  it  is  conceivable,  though  unlikely,  that  there  would  be  a 
"trojan  horse"  embedded  in  the  Emulator  that  would  not  actually  perform  the 
requested  chmod.  For  example,  the  trojan  horse  could  always  set  the  protection 
to  777.  If  the  user  wishes  to  be  absolutely  sure  that  the  chmod  is  done  only  by 
trusted  software,  the  File  Access  Modifier  [NKSR  78)  may  be  employed  at  command 
level.  These  remarks  apply  only  to  the  discretionary  access  information.  The 
hypothetical  trojan  horse  could  not  affect  the  security  level  of  the  file. 
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3. 2. 6-3  Outputs 

The  Emulator  call  chmod  shall  return  the  following  values  after  execution, 
ec:  error  conditions 


The  Emulator  call  chmod  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  directory  needed  for  name  interpretation  is  on  unmounted  file  system 
EX:  file  on  name  interpretation  path  is  not  a  directory 
EX:  directory  on  name  interpretation  path  does  not  exist 
EX:  directory  on  name  interpretation  path  has  search  permission  denied 
EX:  directory  on  interpretation  path  is  at  higher  security  level  (returned 
as  if  directory  did  not  exist) 

EX:  directory  on  interpretation  path  is  at  lower  integrity  level  (returned 
as  if  directory  did  not  exist) 

EX:  file  name  could  not  be  found  in  directory 

EX:  file  is  at  iower  security  level  than  process  (returned  as  if  file  did 
not  exist) 

EX:  file  is  at  higher  integrity  level  than  calling  process  (returned  as  if 
file  did  not  exist) 

EX:  file  does  not  exist 

3.2.7  chown 

The  standard  UNIX  call  chown  has  been  subsumed  into  the  Pile  Access  Modifi¬ 
cation  process  of  the  Non-Kernel  Security  Related  Software  CPCI. 

3.2. 8  close 


3. 2. 8. I  Inputs 

The  Emulator  call  close  shall  take  the  following  parameters, 
fd:  file  descriptor 


3.2. 8. 2  Processing 

The  close  call  shall  terminate  input/output  to  the  specified  file,  device, 
or  pipe.  A  file  descriptor  shall  specify  the  file  to  be  closed.  In  the  PDP- 
11/70  implementation,  the  file  descriptor  shall  be  passed  in  register  R0.  The 
last  close  of  a  file  whose  link  count  has  decremented  to  zero  shall  cause  the 
file  to  be  deleted.  Termination  of  a  process  shall  implicitly  close  all  of  its 
open  files. 

3. 2. 8. 3  Outputs 

The  Emulator  call  close  shall  return  the  following  values  after  execution. 
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ec:  error  conditions 


the  Emulator  call  close  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  Invalid  file  descriptor 


3-2.9  creat 

3. 2. 9. 1  Inputs 

The  Emulator  call  creat  shall  take  the  following  parameters. 

pn:  pointer  to  user  pathname  string  in  user  domain 
da:  discretionary  access  mode  of  new  file 


3.2.9. 2  Processing 

The  Emulator  call  creat  shall  create  a  new  file.  The  file  shall  be  subse¬ 
quently  accessible  by 


a.  the  completely  specified  (rooted)  pathname,  or 

b.  a  concatenation  of  the  process  working  directory  string  and  the  specified 
pathname  string. 

The  file  shall  be  created  with  the  specified  discretionary  access.  (See  the 
remark  in  chmod  about  discretionary  access.)  The  parent  directory  of  the  file 
shall  be  updated  to  include  the  new  file.  The  newly  created  file  shall  have  a 
security  and  integrity  level  oqual  to  that  of  the  calling  process. 

If  the  file  exists,  but  is  at  a  security  level  where  it  Cannot  be  written, 

the  error  return  shall  be  as  if  discretionary  access  to  it  was  denied.  This 
preserves  the  UNIX  construct  of  lock  files. 

An  open  file  descriptor  shall  be  returned  by  creat.  This  descriptor  shall 

be  used  to  reference  the  file  in  subsequent  operations.  The  file  shall  be 

opened  for  writing.  In  the  PDP-11 /70  implementation,  the  file  descriptor  shall 
be  returned  in  register  RO. 

3. 2.9. 3  Outputs 

The  Emulator  call  creat  shall  return  the  following  values  after  execution. 

fd:  open  file  descriptor 
ec:  error  conditions 
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The  Emulator  call  creat  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  security  or  integrity  level  not  permitted  in  file  system  upon  which  the 
file  would  be  created 

EX:  file  system  required  for  pathname  interpretation  is  not  mounted 

EX:  file  name  required  for  pathname  interpretation  is  not  a  directory 

EX:  directory  in  name  interpretation  path  is  unsearchable  or  does  not  exist 

EX:  file  to  be  created  exists  and  is  a  directory 

EX:  directory  to  be  written  is  not  writably  mounted 

EX:  file  does  not  exist  and  write  permission  on  directory  is  denied 

EX:  file  does  exist  and  write  permission  on  it  is  denied 

EX:  too  many  open  files 

3.  2. 10  csw 

The  standard  UNIX  operating  system  call  csw  will  not  be  supported  by  the 
KSOS  Kernel. 

3.2.11  dup 

3.2.11.1  Inputs 

The  Emulator  call  dup  shall  take  the  following  parameters, 
fd:  file  descriptor 


3.2.11.2  Processing 

The  dup  call  shall  allocate  and  return  another  file  descriptor  which  is 
synonymous  with  the  original  descriptor.  The  assignment  algorithm  shall  return 
the  lowest  value  available. 

3.2.11.3  Outputs 

The  Emulator  call  dup  shall  return  the  following  values  after  execution. 

fd:  new  file  descriptor 
ec:  error  conditions 


The  Emulator  call  dup  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  invalid  file  descriptor 
EX:  no  free  file  descriptors 
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3.2.12  eof p 

3.2.12.1  Inputs 

The  Emulator  call  eofp  shall  take  the  following  parameters, 
fd:  file  descriptor  of  pipe 


3.2.12.2  Processing 

(Not  present  in  Version  6.0  UNIX.)  The  Emulator  call  eofp  shall  write  an 
end  of  file  on  a  pipe.  Additional  writes  may  be  performed  on  the  pipe,  but  they 
are  suspended  until  the  eof  has  been  read.  If  the  eofp  call  has  been  issued, 
after  reading  all  the  valid  data,  the  next  read  on  the  pipe  shall  return  0  char¬ 
acters  . 


3.2.12.3  Outputs 

The  Emulator  call  eofp  shall  return  the  following  values  after  execution, 
ec:  error  conditions 


The  Emulator  call  eofp  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  invalid  tile  descriptor  or  file  descriptor  does  not  refer  to  a  pipe 


3.2.13  exec 


3.2.13.1  Inputs 

The  Emulator  call  exec  shall  take  the  following  parameters. 

na:  pointer  to  file  name  string  of  process  prototype  image 
ap:  pointer  to  zero  terminated  list  of  argument  strings 


3.2.13.2  Processing 

The  Emulator  call  exec  shall  overlay  the  current  user  domain  process  image 
with  a  new  image  as  defined  by  the  process  prototype  file.  The  calling  process 
image  shall  be  lost.  Open  files  shall  remain  open  after  the  execution  of  the 
exec  call.  Signal  function  values  shall  be  set  to  the  defaults,  except  for 
Ignored  signals,  which  remain  ignored.  Profiling  shall  be  disabled  by  the  exe¬ 
cution  of  exec.  If  the  process  image  to  be  incarnated  is  privileged  (l.e., 
privilege  bits  in  the  type  independent  information  for  the  file  are  enabled)  the 
effective  process  user  ID  shall  be  updated  accordingly.  Reference  [Thompson  75] 
section  A.OUT(V)  for  the  definition  of  the  process  prototype  file  format. 
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3.2. 13.3  Outputs 

The  Emulator  call  exec  shall  return  the  following  values  after  execution, 
ec:  error  conditions 


The  Emulator  call  exec  shall  detect  and  report  the  following  exception 
(error)  conditions- 

EX:  security  level  of  process  is  too  low  to  execute  (read)  file  (returned  as 
if  file  did  not  exist) 

EX:  integrity  level  of  process  is  too  high  to  execute  (read)  file  (returned 
as  if  file  did  not  exist) 

EX:  process  prototype  file  does  not  exist 

EX:  process  user  ID  does  not  have  execute  permission  to  prototype  file 

EX:  too  many  arguments  (argument  list  too  large)  The  limit  on  Che  size  of 
the  argument  segment  shall  be  no  smaller  than  the  present  limit  (approx¬ 
imate)/  512  characters). 

EX:  file  prototype  format  error 

EX:  not  enough  memory  resources  to  execute  process  image 


3.2.14  exit 


3.2.14.1  Inputs 

The  Emulator  call  exit  shall  take  the  following  parameters, 
es:  exit  status  value 


3.2.14.2  Processing 

The  Emulator  call  exit  shall  cause  the  process  (both  user  and  Emulator 
parts)  to  terminate  execution.  All  open  files  shall  be  closed.  The  parent  pro¬ 
cess  shall  be  notified  of  the  process  termination.  The  exit  status  value  shall 
be  returned  to  the  parent  as  part  of  the  notification.  The  exit  call  shall 
never  return. 

3.2.14.3  Outputs 

The  Emulator  call  exit  shall  return  the  following  values  after  execution. 
None 


The  Emulator  call  exit  shall  detect  and  report  the  following  exception 
(error)  conditions. 

None 
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3 -  2 - 15  fork 


3.2.15.1  Inputs 

The  Emulator  call  fork  shall  take  the  following  parameters. 
None 


3.2.15.2  Processing 

The  Emulator  call  fork  shall  create  a  new  process.  The  new  process  Image 
shall  be  Identical  to  the  parent  (original)  process  Image.  Open  files  shall  be 
passed  to  the  child  (newly  created)  process.  The  child  process  shall  receive 
the  signal  function  values  of  the  parent  process.  If  profiling  Is  enabled  In 
the  parent  process,  profiling  shall  be  Inherited  by  the  child.  The  return  value 
of  the  parenc  process  shall  be  the  process  ID  of  the  child  process.  The  child 
process  shall  receive  the  return  value  zero.  In  the  PDP-11/70  Implementation  of 
KSOS,  the  program  counter  of  the  parent  process  shall  be  Incremented  by  two, 
causing  the  parent  to  return  to  a  different  location  after  the  execution  of 
fork.  The  clandestine  information  channel  offered  by  the  resource  exhaustion 
condition  shall  be  bandwidth  limited  by  the  KSOS  Security  Kernel* 

3.2.15.3  Outputs 

The  Emulator  call  fork  shall  return  the  following  values  after  execution. 

pi:  process  Id  of  child  (returned  to  parent  process),  zero  (returned  to 
child  process) 

The  Emulator  call  fork  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  process  space  exhausted 


3.2.16  fstat 
3.2.16.1  Inputs 


The  Emulator  call  fstat  shall  take  the  following  parameters. 

fd:  file  descriptor  (passed  in  register  RO) 
ba:  buffer  address  for  file  status  information 


3.2.16.2  Processing 

The  fstat  call  shall  return  the  same  information  (except  for  shared  values 
like  link  counts  that  could  be  used  as  channels)  and  in  the  same  format  as  the 
stat  call  below.  The  file  descriptor  shall  refer  to  a  presently  open  (read  or 
read/write  mode)  file.  In  KSOS,  a  file  must  be  readable  with  respect  to 
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mandatory  security  before  the  control  information  can  be  accessed  to  prevent 
clandestine  information  channels. 

3.2. 16.3  Outputs 

The  Emulator  call  fstat  shall  return  the  following  values  after  execution. 

fs:  file  status  information 
ec:  error  conditions 


The  Emulator  call  fstat  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  invalid  file  descriptor 

EX:  file  has  not  been  opened  for  reading 


3.2.17  getal 
3.2.17.1  Inputs 

The  Emulator  call  getal  shall  take  the  following  parameters, 
bp:  pointer  to  buffer  for  access  level  information 


3.2.17.2  Processing 

(Not  present  in  Version  6.0  UNIX.)  The  getal  call  shall  return  the  type 
independent  intormation  for  the  process:  security  classification,  security 
category,  integrity  level,  integrity  category,  and  effective/real  group  and  user 
identifiers.  The  user  identification  information  is  returned  in  the  full  bit- 
precision  supported  by  the  Security  Kernel.  The  user  identification  returned  by 
the  getuid  and  getgid  calls  represents  the  shorter  "mapped"  identifiers  as 
transformed  by  the  Emulator. 

3.2.17.3  Outputs 

The  Emulator  call  getal  shall  return  the  following  values  after  execution, 
al:  process  access  level  information 


The  Emulator  call  getal  shall  detect  and  report  the  following  exception 
(error)  conditions. 


EX:  invalid  buffer  pointer  address 
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3. 2. 18  getgld 

3.2.18.1  Inputs 

The  Emulator  call  getgld  shall  take  the  following  parameters* 
None 


3.2.18.2  Processing 

The  Emulator  call  getgid  shall  return  the  effective  and  real  group  ID  of 
the  process.  In  the  PDP-11 /70  implementation  of  KSOS,  the  high  order  byte  of  RO 
shall  contain  the  effective  ID.  The  low  order  byte  shall  contain  the  real  ID. 
The  real  ID  shall  identify  the  user  who  initiated  execution  of  the  process. 

The  KSOS  Security  Kernel  supports  user  and  group  ID's  which  are  longer  than 
the  8-bits  implemented  in  standard  UNIX.  The  UNIX  Emulator  shall  map  longer 
Kernel  names  to  shorter  UNIX  compatible  identifiers.  (This  note  shall  also 
apply  to  the  Emulator  call  getuid,  below.) 

3.2.18.3  Outputs 

The  Emulator  call  getgld  shall  return  the  following  values  after  execution, 
er:  effective  and  real  group  ID  of  process 


The  Emulator  call  getgid  shall  detect  and  report  the  following  exception 
(error)  conditions. 

None 


3.2.19  getpid 


3.2.19.1  Inputs 

The  Emulator  call  getpid  shall  take  the  following  parameters. 
None 


3.2.19.2  Processing 

The  Emulator  call  getpid  shall  return  the  process  ID  of  the  calling  pro¬ 
cess.  This  name  may  be  a  mapped  version  of  the  longer  Kernel  names  for 
processes  (SEID's). 

3.2.19.3  Outputs 

The  Emulator  call  getpid  shall  return  the  following  values  after  execution. 
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pi:  process  ID  of  calling  process 

The  Emulator  call  getpid  shall  detect  and  report  the  following  exception 
(error)  conditions. 

None 

3.2.20  getuid 

3.2.20.1  Inputs 

The  Emulator  call  getuid  shall  take  the  following  parameters. 

None 

3.2.20.2  getuid 

The  Emulator  call  getuid  shall  return  the  effective  and  real  user  ID  of  the 
calling  process.  In  the  PDP-11/70  implementation  of  KSOS,  the  low  order  byte  of 
R0  shall  contain  the  real  user  ID.  The  high  order  byte  shall  return  the  effec¬ 
tive  user  ID.  See  the  notes  in  getgid  above  for  a  discussion  of  the  uses  ' 
real  and  effective  ID. 

3-2.20.3  Outputs 

The  Emulator  call  getuid  shall  return  the  following  values  after  execution, 
er:  effective  and  real  user  ID  of  calling  process 

The  Emulator  call  getuid  shall  detect  and  report  the  following  exception 
(error)  conditions. 

None 

3-2.21  gprocs 

3.2.21.1  Inputs 

The  Emulator  call  gprocs  shall  take  the  following  parameters, 
ba:  buffer  address  for  process  status  information  (in  register  R0) 

3.2.21.2  Processing 

The  gprocs  call  shall  copy  process  control  information  to  a  buffer  in  the 
calling  user  process  domain.  The  process  control  data  shall  be  at  a  lower  or 
equal  security  level  than  the  caller.  The  number  of  observed  processes  shall  be 
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returned.  Only  Information  about  processes  in  the  process  family  of  the  caller 
shall  be  returned.  In  the  PDP-11/70  implementation  the  returned  in . or mat ion 
shall  adhere  to  the  format  of  the  existing  UNIX  process  table  structure  to  the 
extent  possible.  Security  relevant  information  shall  not  be  returned,  and  KSOS 
relevant  information  may  be  returned  instead. 

3.2.21.3  Outputs 

The '♦Emulator  call  gprocs  shall  recum  the  following  values  after  execution. 

np:  number  of  process  table  entries  returned  to  the  user  process 
ec:  error  conditions 


The  Emulator  call  gprocs  shall  detect  and  report  the  following  exception 
(error)  conditions- 

EX:  bad  buffer  address 


3.2.22  gtty 
3*2.22.1  Inputs 

The  Emulator  call  gtty  shall  take  the  following  parameters, 
fd:  open  file  descriptor 

sb:  pointer  to  data  vector  in  user  domain  for  status  information 


3.2.22.2  Processing 

The  Emulator  call  gtty  shall  return  the  current  status  of  a  device 
currently  open  and  accessible  for  reading  by  the  calling  process. 

3.2.22.3  Outputs 

The  Emulator  call  gtty  shall  return  the  following  values  after  execution. 

ec:  error  conditions 

si:  device  status  information 


The  Emulator  call  gtty  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  invalid  tile  descriptor 

EX:  device  is  not  a  character  mode  device 
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3.2.23  indtr 


3.2.23.1  Inputs 

The  Emulator  call  indir  shall  take  the  following  parameters, 
sc:  pointer  to  location  containing  a  system  call 


3.2.23.2  Processing 

The  indir  Emulator  call  shall  execute  the  system  call  specified  by  the 
pointer  argument.  If  indir  is  executed  indirectly,  no  effect  shall  occur. 
Attempts  to  execute  non-system  calls  shall  result  in  a  process  fault. 

3-2.23.3  Outputs 

The  Emulator  call  indir  shall  return  the  following  values  after  execution, 
ec:  error  conditions 


The  Emulator  call  shall  detect  and  report  the  following  exception  (error) 
conditions . 

EX:  attempt  to  execute  non-system  call 
EX:  invalid  address 


3.2.24  kill 


3. 2.24.1  Inputs 

The  Emulator  call  kill  shall  take  the  following  parameters. 

pi:  process  ID  of  destination  process 
sn:  number  of  signal  to  be  sent 


3.2.24.2  Processing 

The  Emulator  call  kill  shall  send  the  specified  signal  to  the  destination 
process.  It  shall  not  be  possible  for  a  process  to  kill  itself.  In  the  PDP- 
11/70  implementation  of  KSOS ,  the  process  number  shall  be j>assed  in  register  RO. 
An  error  shall  be  detected  and  returned  if  the  destination  process  has  denied 
IPC  writes  via  setting  the  discretionary  access  information  for  the  process. 

3.2.24.3  Outputs 

The  Emulator  call  kill  shall  return  the  following  values  after  execution, 
ec:  error  conditions 
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The  Emulator  call  kill  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  destination  process  is  the  calling  process 

EX:  destination  process  has  denied  IPC  writes  to  it  (returned  as  if  the  pro¬ 
cess  did  not  exist) 

EX:  destination  process  does  not  exist 
EX:  signal  number  is  less  than  zero 

EX:  signal  number  is  greater  than  the  Emulator  maximum 

3.2.25  link 

3.2.25.1  Inputs 

The  Emulator  call  link  shall  take  the  following  parameters. 

dn:  pathname  of  file  to  which  the  link  shall  be  made 
In:  pathname  of  the  link 


3.2.25.2  Processing 


The  link  Emulator  call  shall  create  a  link  to  a  file  with  the  specified 
pathname.  The  pathname  interpretation  and  verification  algorithm  shall  be 
applied  to  both  specified  pathnames.  The  full  semantics  of  UNIX  links  shall  be 
retained  in  KSOS . 


3.2.25.3  Outputs 


The  Emulator  call  link  shall  return  the  following  values  after  execution. 


ec:  error  conditions 


The  Emulator  call  link  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  file  system  required  for  name  interpretation  is  not  mounted 
EX:  file  required  for  name  interpretation  is  not  a  directory 
EX:  directory  on  path  is  at  a  higher  security  level  (returned  as  if  the 

directory  did  not  exist) 

EX:  directory  on  path  is  at  a  lower  integrity  level  (returned  as  if  the 

directory  did  not  exist) 

EX:  directory  on  path  has  search  permission  denied 
EX:  link  name  already  exists 

EX:  security  level  of  directory  to  be  written  is  higher  than  caller 
(returned  as  if  there  were  no  write  permission  on  the  directory) 

EX:  integrity  level  of  directory  to  be  written  is  lower  than  caller 
(returned  as  if  there  were  no  write  permission  on  the  directory) 

EX:  write  permission  to  directory  has  been  denied 
EX:  attempt  to  link  across  tile  systems 
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3.2.26  mknod 


3.2.26.1  Inputs 

The  Emulator  call  mknod  shall  take  the  following  parameters. 

pn:  pointer  to  new  file  pathname 

da:  discretionary  access  mode  ot  new  file 

ad:  "address"  field  (retained  for  UNIX  compatibility) 


3.2.26.2  Processing 

The  Emulator  call  mknod  shall  create  a  new  file  with  the  specified  path¬ 
name.  The  discretionary  access  mode  of  the  .iew  file  shall  be  set  to  the  speci¬ 
fied  mode.  (See  the  comments  on  chraod.)  A  directory  shall  (in  all  cases)  be 
created.  The  creation  of  special  (device)  files  shall  be  accomplished  through 
system  generation  and  NKSR  Software  functions.  Unlike  standard  UNIX,  regular 
user  processes  shall  be  able  to  create  directories.  Regular  user  processes 
shall  not  be  able  to  write  directly  to  directories  as  regulated  by  the  Kernel 
subtype  mechanism. 

3.2.26.3  Outputs 

The  Emulator  call  mknod  shall  return  the  following  values  after  execution, 
ec:  error  conditions 


The  Emulator  call  mknod  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  insufficient  integrity  level  to  create  a  special  file 
EX:  file  in  the  searchable  path  is  not  a  directory 

EX:  file  system  required  for  pathname  interpretation  is  not  mounted 
EX:  tile  exists  with  the  same  pathname 


3.2.27  mount 

The  mount  UNIX  call  has  been  replaced  by  the  mount  mechanism  of  the  Non' 
Kernel  Security-Related  Software  which  has  the  same  functionality. 

3.2.28  nice 
3.2.28.1  Inputs 

The  Emulator  call  nice  shall  take  the  following  parameters, 
np:  new  process  priority  (passed  in  RO) 
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3.2.28.2  Processing 

The  Emulator  call  nice  shall  advise  the  scheduler  of  a  new  runtime  prior¬ 
ity.  This  new  priority  shall  only  be  an  advisory.  That  is,  it  shall  be  the 
responsibility  of  the  scheduler  to  guarantee  equitable  service.  The  legal 
values  which  the  new  priority  may  assume  shall  be  greater  than  zero  and  less 
than  some  maximum,  currently  twenty  (2J.) 

3.2.28.3  Outputs 

The  Emulator  call  nice  shall  return  the  following  values  after  execution, 
ec:  error  conditions 


The  Emulator  call  nice  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  new  priority  is  less  than  zero 

EX:  new  priority  greater  than  system  maximum 


3.2.29  open 

V 

3.2.29.1  Inputs 

The  Emulator  call  open  shall  take  the  following  parameters. 

pn:  pointer  to  pathname  string  of  file  to  be  opened 
md:  requested  access  mode  {  read,  write,  read  and  write) 


3.2.29.2  Processing 

The  Emulator  call  open  shall  open  the  designated  file  for  reading  and/or 
writing.  A  file  descriptor  shall  be  returned  for  use  in  subsequent  references 
to  the  file. 

3.2.29.3  Outputs 


The  Emulator  call  open  shall  return  the  following  values  after  execution. 

fd:  file  descriptor  (returned  in  register  RO) 
ec :  error  conditions 


The  Emulator  call  open  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  file  required  for  name  interpretation  is  not  a  directory 
EX:  file  system  required  for  name  interpretation  is  not  mounted 
EX:  directory  on  path  is  at  higher  security  level  (returned  as  if  the  direc¬ 
tory  did  not  exist) 
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EX:  directory  on  path  Is  at  lower  integrity  level  (returned  as  if  the  direc¬ 
tory  did  not  exist) 

EX:  search  permission  on  a  pathname  directory  is  denied 

EX:  file  is  at  a  higher  security  level  and  reading  is  requested  (returned  as 
if  the  file  has  read  access  denied) 

EX:  file  is  at  a  lower  security  level  and  writing  is  requested  (returned  as 
if  the  file  had  write  access  denied) 

EX:  file  is  at  a  lower  integrity  level  and  reading  is  requested  (returned  as 
if  the  file  had  read  access  denied) 

EX:  file  is  at  a  higher  integrity  level  and  writing  is  requested  (returned 
as  if  the  file  has  write  access  denied) 

EX:  discretionary  permission  is  denied  for  writing,  write  requested 

EX:  discretionary  permission  is  denied  for  reading,  reading  requested 

EX:  too  many  files  are  open 

3.2. 3C  pipe 

3.2.30.1  Inputs 

The  Emulator  call  pipe  shall  take  the  following  parameters. 

None 


3.2.30.2  Processing 

The  Emulator  call  pipe  shall  create  an  input/output  pipe.  Two  open  file 
descriptors  shall  be  returned,  one  for  input  and  a  second  for  output.  In  the 
PDP-11/70  implementation,  the  read  file  descriptor  shall  be  returned  in  register 
R0.  The  write  file  descriptor  shall  be  returned  in  register  Rl.  Two  available 
open  file  slots  shall  be  required  to  successfully  perform  the  pipe  call. 

3.2.30.3  Outputs 

The  Emulator  call  pipe  shall  return  the  following  values  after  execution. 

rf :  read  file  descriptor 
wf :  write  file  descriptor 


The  Emulator  call  pipe  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  Loo  many  files  open 


3.2.31  port 


3.2.31.1  Inputs 

The  Emulator  call  port  shall  take  the  following  parameters. 
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pn:  port  pathname  string 
mo:  access  mode  for  port 

pf :  pointer  to  a  two  integer  block  for  returned  file  descriptors 


3-2. 31  -  2  Processing 

(Not  present  in  Version  6.0  UNIX.)  Ports  are  a  generalization  of  pipes. 
The  port  Emulator  call  shall  create  and  open  a  new  port.  The  specified  pathname 
shall  be  either  a  complete  pathname,  a  pathname  relative  to  the  process  working 
directory,  or  the  null  string.  Ports  with  the  null  string  as  their  name  shall 
be  inaccessible  by  other  processes.  The  port  shall  be  at  the  same  security  and 
integrity  level  of  the  calling  process.  The  mode  parameter  shall  determine  the 
format  of  the  message  headers  attached  at  port  data  during  write  operations. 
The  mode  parameter  shall  also  specify  the  write  access  to  the  port  accorded  to 
the  creator,  the  creator's  group  and  all  other  users.  ([Zucker  77]  and 
[Sunshine  77]  discuss  the  supporting  concepts  and  mechanization  of  ports  in  RAND 
UNIX.) 

3.2.31.3  Outputs 

The  Emulator  call  port  shall  return  the  following  values  after  execution. 

fr:  file  descriptor  for  reading  (also  returned  in  register  RO) 
fw:  file  descriptor  for  writing 

The  Emulator  call  port  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  improper  mode 

EX:  directory  needed  to  interpret  pathname  is  unmounted 
EX:  file  on  name  interpretation  path  is  not  a  directory 
EX:  search  permission  denied  for  directory  on  interpretation  path 
EX:  attempted  violation  of  mandatory  security  during  name  interpretation 
(returned  as  if  directory  had  search  permission  denied) 

EX:  invalid  pointer  address  for  file  descriptors 
EX:  port  already  exists 


3.2.32  protil 
3. 2. 32. 1  Inputs 

The  Emulator  call  profil  shall  take  the  following  parameters- 

bp:  pointer  to  histogram  buffer  in  user  domain 
bs:  buffer  size  (in  bytes) 

os:  offset  to  be  subtracted  from  sampled  program  counter 
sc:  scale  to  expand/contract  observation 
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3.2.32.2  Processing 

The  Emulator  call  profil  shall  cause  an  execution  profile  to  be  compiled 
into  a  data  vector  in  the  user  process  domain.  The  user  program  counter  will  be 
sampled  each  1/10  of  a  second  thereafter  while  the  process  is  physically  execut¬ 
ing.  Offset  and  scale  shall  be  used  to  adjust  the  program  counter  value  to  an 
index  within  che  bounds  of  the  histogram  vector.  If  the  resulting  value  is 
within  the  histogram  vector,  che  observation  is  tallied.  See  [Thompson  75]  for 
data  types  and  formats. 

In  the  PDP-11 /70  implementation  of  KSOS ,  profiling  shall  be  disabled  by 
specifying  a  scale  of  zero  or  one-  Profiling  shall  be  rendered  ineffective  if 
the  buffer  size  is  zero.  The  execution  of  the  call  exec  will  disable  profiling- 
Profiling  shall  remain  enabled  in  both  parent  and  child  after  a  fork  call. 

3.2*32.3  Outputs 

The  Emulator  call  profil  shall  return  the  following  values  after  execution* 

ht:  histogram  tallies  in  the  data  vector 
ec:  error  conditions 


The  Emulator  call  profil  shall  detect  and  report  the  following  exception 
(error)  conditions- 

EX:  improper  buffer  address  in  user  process  (not  checked  in  6.0  UNIX.) 

EX:  buffer  size  too  large  (not  checked  in  6.0  UNIX.) 


3.2.33  ptrace 
3.2.33.1  Inputs 

The  Emulator  call  ptrace  shall  take  the  following  parameters, 
rq:  requested  trace  action 

pi:  process  ID  of  traced  (destination)  process 

ad:  address  parameter  to  action 

da:  data  parameter  to  requested  action 


3.2.33.2  Processing 

The  Emulator  call  ptrace  shall  permit  a  parent  process  to  control  and  moni¬ 
tor  the  execution  of  an  immediate  child  process.  Tracing  of  set-uid  software 
shall  not  be  permitted.  The  behavior  of  the  ptrace  call  shall  depend  upon  the 
interpretation  of  the  requested  action  parameter.  In  the  PDP-11/70  Implementa¬ 
tion  of  KSOS,  the  following  action  values  and  actions  shall  be  supported. 

0.  executed  by  child.  Indicates  that  child  expects  to  be  traced. 

1,2.  get  instruction  space  or  data  space  word,  respectively,  from  the  child 
process. 
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3*  returned  the  addressed  word  from  the  per-process  data  table* 

4,5.  set  word  in  the  child  instruction  or  data  space,  respectively. 

6.  write  the  per-process  data  word  as  addressed. 

7.  force  a  signal  to  the  child  process. 

8.  terminate  the  traced  process. 

With  the  exception  of  request  zero  (0),  the  traced  process  shall  be  stopped 
prior  to  execution  of  the  tracing  action.  The  wait  call  shall  be  used  to  deter¬ 
mine  when  a  process  has  stopped.  Processes  that  have  stopped  shall  return  to 
the  waiting  parent  the  termination  status  value  of  0177  (octal.) 

Because  ptrace  may  be  implemented  using  the  low  bandwidth  IPC  mechanism, 
the  usual  security,  integrity,  and  discretionary  controls  enforced  by  the  Kernel 
may  limit  the  extent  of  process  tracing. 

3.2.33.3  Outputs 

The  Emulator  call  ptrace  3hall  return  the  following  values  after  execution. 

dv:  data  values 
ec:  error  conditions 


The  Emulator  call  ptrace  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  request  value  is  out  of  bounds  (less  than  0  or  more  than  8) 

EX:  requested  action  zero  and  parent  does  not  exist 
EX:  destination  process  does  not  exist 

EX:  destination  process  has  denied  IPC  writes  to  it  (returned  as  if  process 
did  not  exist) 

EX:  destination  process  is  not  an  immediate  descendant  of  caller 

EX:  requested  data  read  or  write  and  address  was  odd 

EX:  requested  data  read  or  write  and  addressing  error  resulted 

3. 2. 34  read 
3.2.34.1  Inputs 

The  Emulator  call  read  shall  take  the  following  parameters. 

fd:  file  descriptor  (passed  in  register  R0) 
ba:  pointer  to  buffer  for  incoming  data 
nb :  number  of  bytes  to  be  read  (if  possible) 


3.2.34.2  Processing 

The  read  call  shall  transfer  data  from  the  specified  file,  device,  or  pipe 
to  a  buffer  in  the  process  user  domain.  The  number  of  bytes  specified  in  the 
call  shall  be  transfered  if  possible.  The  actual  number  of  bytes  read  shall  be 
returned.  In  the  PDP-11 /70  implementation,  the  actual  byte  count  shall  be 
returned  in  register  R0.  The  value  zero  shall  be  returned  when  end  of  file  has 
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been  reached. 

3.2.34.3  Outputs 

The  Emulator  call  read  shall  return  the  following  values  after  execution. 

db :  data  bytes  to  the  user  domain  buffer 
ac :  actual  count  of  data  bytes  transfered 


The  Emulator  call  read  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  invalid  file  descriptor 

EX:  file  has  not  been  opened  for  reading 

EX:  attempt  to  read  from  pipe  without  a  writer  at  the  other  end 
EX:  physical  device  error 
EX:  illegal  buffer  address 


3.2. 35  seek 


3. 2. 35. 1  Inputs 

The  Emulator  call  seek  shall  take  the  following  parameters. 

fd:  file  descriptor  (passed  in  register  RO) 

os:  logical  offset  within  file 

pr:  requested  pointer  adjustment  action 


3.2.35.2  Processing 

The  Emulator  call  seek  shall  adjust  the  logical  file  pointer  for  the  desig¬ 
nated  open  file.  The  pointer  shall  be  adjusted  according  to  the  requested 
action  as  follows. 

0:  the  poincer  shall  be  set  exactly  to  the  parameter  offset. 

1:  the  poincer  shall  be  set  to  the  current  seek  pointer  value  plus  the 
offset . 

2:  the  pointer  is  set  to  the  length  of  the  file  plus  the  offset. 

3,4,5:  the  pointer  shall  be  set  as  In  0,1,2  above  but  offset  shall  be  multi¬ 
plied  by  512  before  updating  the  pointer. 

Absolute  offset  values  shall  be  unsigned  (case  0  and  3  above.)  The  offset  shall 
otherwise  be  signed. 

3.2.35.3  Outputs 

The  Emulator  call  seek  shall  return  the  following  values  after  execution. 
:c:  error  conditions 
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The  Emulator  call  seek  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  invalid  file  descriptor 

EX:  file  descriptor  refers  to  a  pipe 

EX:  requested  action  is  out  of  bounds  (pr  <  0  or  pr  >  5) 


3.2.36  setgid 

3.2.36.1  Inputs 

The  Emulator  call  setgid  shall  take  the  following  parameters, 
gi:  new  group  id 


3.2.36.2  Processing 

The  Emulator  call  setgid  shall  set  the  effective  group  id  of  the  calling 
process.  Processes  which  are  appropriately  privileged  shall  also  set  the  real 
group  id  (i.e.,  the  owner)  of  the  process.  Unprivileged  processes  shall  be  per¬ 
mitted  to  set  the  effective  group  id  to  the  value  of  the  real  group  id  only. 

3.2.36.3  Outputs 

The  Emulator  call  setgid  shall  return  the  following  values  after  execution, 
ec:  error  conditions 


The  Emulator  call  setgid  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  attempt  to  set  effective  group  id  to  value  other  than  real  group  id 

3.2.37  setuid 
3.2.37.1  Inputs 

The  Emulator  call  setuid  shall  take  the  following  parameters  - 
nu:  new  effective  user  id 


3.2.37.2  Processing 

The  Emulator  call  setuid  shall  set  the  effective  user  id  of  the  calling 
process.  Processes  which  are  appropriately  privileged  shall  also  set  the  real 
user  id  (i.e.,  the  owner)  of  the  process.  Unprivileged  processes  shall  be  per¬ 
mitted  to  set  the  effective  user  id  to  the  value  of  the  real  user  id  only. 
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3.2.37.3  Outputs 

The  Emulator  call  setuid  shall  return  the  following  values  after  execution, 
ec:  error  conditions 


The  Emulator  call  setuid  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  attempt  to  set  effective  user  Id  to  value  other  than  real  user  Id 

3.2.38  stork 
3.2.38.1  Inputs 

The  Emulator  call  sfork  shall  take  the  following  parameters. 

Hone 


3.2.38.2  Processing 

The  sfork  call  shall  spawn  a  new  process.  The  process  creation  function  of 
this  call  shall  be  identical  to  the  Emulator  call  fork.  (See  "fork"  above.)  The 
children  generated  by  this  call  shall  be  Immune  from  terminal  generated  Inter¬ 
rupt  (DEL  character)  or  quit  (FS  character)  signals.  The  children  shall  still 
receive  direct  signals  from  the  kill  Emulator  call.  (See  "kill"  above.) 

3.2.38.3  Outputs 

The  Emulator  call  sfork  shall  return  the  following  values  after  execution. 
Identical  to  fork 


The  Emulator  call  stork  shall  detect  and  report  the  following  exception 
(error)  conditions- 

Identical  to  fork 


3.2.39  signal 
3.2.39.  I  Inputs 

The  Emulator  call  signal  shall  take  the  following  parameters. 

sn :  signal  number 
sf :  signal  function 
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3.2.39.2  Processing 

The  Emulator  call  signal  shall  permit  the  user  to  specify  the  recovery 
action  to  be  taken  following  the  reception  of  a  signal  from  another  process. 
The  PDP-11/70  Implementation  of  KSOS  shall  provide  for  a  minimum  of  thirteen 
(13)  signals.  The  signal  conditions  shall  be: 

1.  hangup 

2.  Interrupt 

3.  quit  (core  image) 

4.  illegal  instruction  (not  reset  when  caught  -  core  image) 

5.  trace  trap  (not  reset  when  caught  -  core  image) 

6.  IOT  instruction  (core  image) 

7.  EMT  instruction  (Kernel  call  -  effect  differs  from  standard  UNIX) 

8.  floating  point  exception  (core  Image) 

9.  kill  (cannot  be  caught  or  ignored) 

10.  bus  error  (core  image) 

11.  segmentation  violation  (core  image) 

12.  bad  argument  to  system  call  (core  image) 

13.  write  on  a  pipe  with  no  one  to  read  it 

Note  the  difference  from  standard  UNIX  In  signal  number  seven  (7.)  The  user  part 
of  a  process  shall  be  able  to  directly  call  the  Security  Kernel.  Because  the 
EMT  instruction  shall  be  used  to  invoke  the  Kernel,  the  semantics  of  signal 
number  seven  must  change.  This  signal  slot  shall  be  retained  for  historical 
reasons.  Core  dump  images  shall  be  generated  for  the  signals  so  marked  above. 

The  PDP-11/70  implementation  of  KSOS  shall  comply  with  the  standard  UNIX 
signal  semantics  relevant  to  the  significance  of  signal  function  values  and  sig¬ 
nal  routine  return  procedures.  If  the  signal  function  value  is  zero,  the  pro¬ 
cess  shall  terminate  when  the  specified  signal  Is  received.  This  shall  be  the 
default  action.  If  the  signal  function  value  is  odd,  the  signal  shall  be 
ignored  except  where  noted  in  the  list  above.  An  even  valued  signal  function 
shall  specify  the  address  in  the  user  domain  of  the  signal  handling  routine. 
This  routine  shall  be  entered  following  the  reception  of  the  specified  signal. 
A  PDP-11 /70  RTI  or  RTT  instruction  shall  return  from  the  signal  Interrupt.  Sig¬ 
nals  which  have  been  caught  shall  cause  the  selected  action  to  be  reset  to  zero. 
The  number  of  signals  to  be  set  shall  be  a  parameter  to  the  Emulator  generation 
procedure.  The  number  shall  not  be  less  than  thirteen. 

3.2.39.3  Outputs 

The  Emulator  call  signal  shall  return  the  following  values  after  execution. 

ec:  error  conditions 
ov:  old  signal  value 


The  Emulator  call  signal  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  specified  signal  number  is  less  than  zero 

EX:  specified  signal  number  is  greater  than  the  maximum  number  of  signals 
permitted  by  the  Emulator 
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EX:  specified  signal  is  the  kill  signal  (number  9) 

3.2.40  sleep 

3.2.40.1  Inputs 

The  Emulator  call  sleep  shall  take  the  following  parameters, 
st:  sleep  time  in  seconds 

3.2.40.2  Processing 

The  Emulator  call  sleep  shall  suspend  execution  for  the  Lime  period  speci¬ 
fied  by  Lhe  parameter. 

3.2.40.3  Outputs 

The  Emulator  call  sleep  shall  return  the  following  values  after  execution. 
None 


The  Emulator  call  sleep  shall  detect  and  report  the  following  exception 
(error)  conditions. 

None 


3.2.41  stat 
3.2.41.1  Inputs 

The  Emulator  call  stat  shall  take  the  following  parameters. 

pn:  pointer  to  pathname  string 

ba:  buffer  address  for  file  status  information 


3.2.41.2  Processing 

The  Emulator  call  stat  shall  return  the  file  status  information  for  the 
specified  file.  In  the  PDP-11 /70  implementation  of  KSOS,  th»  format  of  the 
information  to  be  returned  shall  be  consistent  with  the  existing  call  except  for 
such  information  which  is  meaningless  under  KSOS.  These  fields  may  be  used  for 
KSOS  specific  information.  Certain  values  (e.g.  link  count,  time  of  last 
access)  may  not  be  returned  since  they  may  be  used  as  clandestl  <e  information 
channels.  The  access  checks  of  the  corresponding  open  call  shall  be  satisfied 
in  order  for  Lhis  call  to  succeed.  If  the  file  exists,  but  cannot  be  accessed 
due  to  mandatory  security,  integrity,  or  discretionary  access  reasons,  a  dis¬ 
tinctive  null  status  block  shall  be  returned,  however,  the  error  condition  shall 
not  be  raised. 
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3.2.41.3  Outputs 

The  Emulator  call  stat  shall  return  the  following  values  after  execution. 

fs:  file  status  information 
ec:  error  conditions 


The  Emulator  call  stat  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  file  system  required  for  pathname  interpretation  is  not  mounted 
EX:  file  required  for  pathname  interpretation  is  not  a  directory 
EX:  directory  on  path  is  unsearchable 


EX: 

directory 

on 

path  is  at 

higher 

security 

level 

and 

Is 

unreadable 

(returned 

as 

if  directory 

was  unsearchable) 

EX: 

direc  tory 

on 

path  is  at 

lower 

integrity 

level 

and 

Is 

unreadable 

(returned  as  if  directory  was  unsearchable) 
EX:  file  does  not  exist 


3.2.42  stime 

The  stime  UNIX  call  has  been  replaced  bv  equivalent  functionality  in  the 
Non-Kernel  Security-Related  Software. 

3.2.43  sttv 
3.2.43.1  Inputs 

The  Emulator  call  stty  shall  take  the  following  parameters. 

fd:  file  descriptor 

pp:  pointer  to  parameter  block 

pb:  device  control  parameter  block 


3.2.43.2  Processing 

The  Emulator  call  stty  shall  set  the  device  dependent  control  parameters 
for  the  device  referenced  by  the  file  descriptor.  The  format  of  the  parameter 
block  9hall  be  the  same  as  the  existing  call.  Unlike  Version  6.0  UNIX,  the  user 
must  own  the  device  for  this  call  to  be  effective. 

3.2.43.3  Outputs 

The  Emulator  call  stty  shall  return  the  following  values  after  execution, 
ec:  error  conditions 


The  Emulator  call  stty  shall  detect  and  report  the  following  exception 
(error)  conditions. 
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EX:  Invalid  tile  descriptor 

EX:  device  Is  not  a  character  mode  device 

EX:  not  owner  of  the  device 

EX:  parameters  Invalid  (stty  Can  be  used  for  other  devices  which  may  include 
additional  checking  on  the  parameter  block) 


3. 2. 44  sync 

3.2.44.1  Inputs 

The  Emulator  call  sync  shall  take  the  following  parameters. 
None 


3.2.44.2  Processing 

The  Emulator  call  sync  shall  cause  all  file  system  information  for  the  pro¬ 
cess  family  to  be  updated. 

3.2.44.3  Outputs 

The  Emulator  call  sync  shall  return  the  following  values  after  execution, 
ec:  error  conditions 


The  Emulator  call  sync  shall  detect  and  report  the  following  exception 
(error)  conditions. 


None  • 


3. 2.45  time 
3.2.45.  1  Inputs 

The  Emulator  call  time  shall  take  the  following  parameters. 
None 


3.2.45.2  Processing 

The  Emulator  call  time  shall  return  the  system  time  In  seconds  expired 
since  January  1,  1970.  The  system  time  shall  be  expressed  in  Greenwich  Mean 

Time  (GMT). 

3.2.45.3  Outputs 

The  Emulator  call  time  shall  return  the  following  values  after  execution. 
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tl:  time  in  GMT  since  January  1,  1970  (returned  in  R0  and  Rl) 


The  Emulator  call  time  shall  detect  and  report  the  following  exception 
(error)  conditions. 

None 


3.2.46  times 

3.2.46.1  Inputs 

The  Emulator  call  times  shall  take  the  following  parameters, 
tb:  pointer  to  data  Vector  in  user  domain  for  execution  time  data 

3.2.46.2  Processing 

The  times  Emulator  call  shall  return  the  time-accounting  information  for 
the  currently  executing  process  and  its  terminated  children.  The  times  shall  be 
expressed  in  1/10  seconds.  The  relevant  information  returned  shall  be  Lhe  time 
spent  by  the  process  in  user  mode  and  Emulator  mode  execution,  and  the  time 
spent  by  the.  terminated  children  in  user  mode  and  Emulator  mode  execution.  The 
time  elapsed  in  Kernel  mode  execution  shall  not  be  returned  since  this  data 
opens  a  clandestine  information  channel  through  the  Security  Kernel. 

3.2.46.3  Outputs 

The  Emulator  call  times  shall  return  the  following  values  after  execution- 

pu:  process  user  mode  execution  ' ime 
ps :  process  Emulator  mode  execution  time 
cu:  terminated  child  process  user  mode  execution  Lime 
cs:  terminated  child  process  Emulator  mode  execution  time 
ec:  error  conditions 

The  Emulator  call  times  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  improper  buffer  address  (not  checked  in  Version  6.0  UNIX.) 


3.2.47  umount 

The  UNIX  u(n)mount  call  shall  be  replaced  by  equivalent  functionality  in 
the  Non-Kernel  Security-Related  Software. 
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3.2.4S  unlink 
3.2.48.1  Inputs 

The  Emulator  call  unlink  shall  take  the  following  parameters, 
pn:  pointer  to  file  pathname  string 


3.2.48.2  Processing 

The  unlink  Emulator  call  shall  remove  the  directory  entry  for  a  file.  If 
this  was  the  last  reference  (link)  to  the  file,  the  file  contents  shall  be 
deleted.  If  the  file  is  currently  open,  the  actual  removal  shall  be  delayed 
until  the  file  has  been  closed.  The  directory  entry  shall  be  removed  immedi¬ 
ately. 


3.2.48.3  Outputs 

The  Emulator  call  unlink  shall  return  the  following  values  after  execution, 
ec:  error  conditions 


The  Emulator  call  unlink  shall  detect  and  report  the  following  exception 
(error)  conditions. 

• 

EX:  file  does  not  exist 

EX:  file  system  needed  to  interpret  pathname  is  not  mounted 
EX:  file  on  interpretation  path  is  not  a  directory 
EX:  directory  on  name  interpretation  path  has  search  access  denied 
EX:  directory  on  interpretation  path  is  at  higher  security  level  (returned 
as  if  directory  had  search  access  denied) 

EX:  directory  on  interpretation  path  is  at  lower  integrity  level  (returned 
as  if  directory  had  search  access  denied) 

EX:  file  to  be  removed  is  at  lower  Security  level  (returned  as  if  file  had 
write  access  denied) 

EX:  file  to  be  removed  is  at  higher  integrity  level  (returned  as  if  file  had 
write  access  denied) 

EX:  file  to  be  removed  has  write  permission  denied 
EX:  parent  directory  of  file  has  write  access  denied 
EX:  file  to  be  removed  is  a  directory  and  is  not  empty 


3.2.49  wait 


3.2.49.1  Inputs 

The  Emulator  call  wait  shall  take  the  following  parameters. 


None 
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3.2.49.2  Processing 

The  Emulator  call  wait  shall  cause  the  executing  process  to  suspend  execu¬ 
tion  until  the  termination  of  one  of  its  children.  If  no  children  exist,  the 
return  shall  be  immediate  with  the  appropriate  error  code. 

In  the  PDP-11/70  implementation  of  KSOS,  the  normal  return  shall  present 
the  process  ID  of  the  terminated  child  to  the  parent  in  RO.  The  high  order  byte 
of  R1  shall  contain  upon  return,  the  exit  status  of  the  process  (see  exit 
above.)  The  low  order  byte  of  R1  shall  contain  the  termination  status  of  the 
child  process.  The  following  values  shall  be  used  to  represent  specific  termi¬ 
nation  circumstances. 

0:  normal  termination. 

0177:  stopped,  but  not  terminated.  (see  ptrace  below.) 

0200:  terminated,  core  image  produced. 

3.2.49.3  Outputs 

The  Emulator  call  wait  shall  return  the  following  values  after  execution- 

pi:  process  ID  of  terminated  child  (returned  in  R0'> 

rs:  child  return  status  from  its  exit  (R1  high  order  byte) 

ts:  child  termination  status  (R1  low  order  byte) 


The  Emulator  call  wait  shall  detect  and  report  the  following  exception 
(error)  conditions. 


EX:  no  children  belonging  to  Calling  process 


3.2.50  write 


3.2.50.1  Inputs 

The  Emulator  call  write  shall  take  the  following  parameters. 

fd:  file  descriptor  (passed  in  register  R0) 
ba:  buffer  address  of  data  vector  to  be  written 
nb:  number  of  bytes  to  be  written 


3.2.50.2  Processing 

The  write  call  shall  transfer  data  from  the  process  user  domain  to  the 
specified  file,  device  or  pipe.  The  number  of  bytes  actually  written  shall  be 
returned.  This  count  shall  be  returned  in  register  R0,  in  the  case  of  the  PDP- 
11/70  KSOS  implementation.  If  an  error  has  resulted,  the  actual  byte  count 
shall  differ  from  the  requested  transfer  count* 
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3.2.50.3  Outputs 

The  Emulator  call  write  shall  return  the  following  values  after  execution. 

be:  number  of  bytes  actually  written 
ec:  error  conditions 


Hie  Emulator  call  write  shall  detect  and  report  the  following  exception 
(error)  conditions. 

EX:  invalid  file  descriptor 

EX:  file  has  not  been  opened  for  writing 

EX:  attempt  to  write  a  pipe  without  a  reader  at  the  other  end 

EX:  physical  input/output  error 

EX:  illegal  buffer  address 

EX:  invalid  requested  transfer  count 


3.2.51  Directory  Manager 

The  FCSOS  Emulator  shall  use  the  file  subtype  capability  of  the  Security 
Kernel  to  implement  UNIX  compatible  directories.  For  a  detailed  discussion  of 
Kernel  level  file  subtypes,  the  reader  is  referred  to  the  KSOS  Security  Kernel 
Computer  Program  Development  Specif ication  (Type  B5)  [Kernel  78].  For  this  dis¬ 
cussion,  it  is  sufficient  to  state  that  the  Kernel  file  subtype  mechanism  shall 
permit  the  overall  set  of  file  resources  to  be  divided  into  subtype  partitions. 
In  order  to  access  a  file  within  a  particular  subtype  partition,  the  process 
shall  meet  the  discretionary  access  conditions  predefined  for  files  of  that  sub- 
type,  in  addition  to  the  usual  mandatory  security,  integrity  and  discretionary 
access  conditions.  Access  to  tiles  within  a  subtype  shall  be  granted  on  the 
basis  of  the  requested  access  mode  (i.e.,  read,  write,  execute  (or  search))  and 
the  access  codes  permitted  to  the  requestor.  The  categories  to  which  a  user  may 
belong  shall  be  file  subtype  owner,  user  group,  and  the  set  of  all  users,  con¬ 
forming  to  the  usual  notion  of  UNIX  discretionary  access  permissions. 

The  following  paragraphs  describe  one  possible  implementation  of  the  Direc¬ 
tory  Manager.  The  method  presented  below  is  a  minimum  privilege  solution.  It 
only  requires  the  Directory  Manager  to  temporarily  execute  in  the  discretionary 
access  domain  of  the  directory  subtype  owner  and  that  the  Directory  Manager  be 
privileged  to  use  the  K_link  and  K_unlink  Kernel  calls*  These  privileges  are 
insufficient  to  allow  the  a  Directory  Manage*-  say,  the  SECRET  level  to 
create  a  directory  entry  in  an  UNCLASSIFIED  direct.  .  his  would  require  that 
the  Directory  Manager  also  be  privileged  to  violate  '-a  security  *-property. 
Should  the  Government  require  chat  the  Directory  Manager  De  able  to  manipulate 
directories  that  are  at  security  levels  different  than  its  (the  Directory 
Manager's)  current  level,  the  Directory  Manager  shall  be  privileged  to  violate 
the  security  ^-property,  and  shall  control  the  bandwidth  of  the  resulting 
storage  channel.  This  privileged  version  of  the  Directory  Manager  shall  also 
create  the  appropriate  audit  information  whenever  it  actually  violates  the  secu¬ 
rity  *-property,  and  send  the  audit  information  via  an  1PC  message  to  the  Audit 
Capture  Process  [NKSR  78]. 
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To  support  search-only  directories,  the  directory  manager  must  be  able  to 
read  execute-only  files.  Therefore  the  directory  manager  shall  be  privileged  to 
violate  discretionary  access  in  order  to  perform  path  name  interpret  functions 
on  search  only  directories. 

3.2.51.1  Inputs 

KSOS  Emulator  files  shall  belong  to  one  of  two  file  subtypes,  ordinary 
files  and  directory  tiles.  All  user  processes  shall  have  read,  write,  and  exe¬ 
cute  permission  to  ordinary  files  as  defined  by  the  subtype  discretionary  per¬ 
missions.  (Of  course,  before  a  user  process  can  successfully  access  an  ordinary 
file,  the  mandatory  security  and  owner-permitted  discretionary  access  conditions 
shall  be  fulfilled.)  Directory  files,  however,  shall  have  the  following  file 
subtype  permissions: 

a.  file  subtype  owner:  read,  write,  execute  (search)  enabled 

b.  subtype  owner  group:  read,  write,  execute  (search)  enabled 

C.  all  other  users:  read  and  execute  (search)  enabled 

All  KSOS  users  shall  be  able  to  read  and  search  directory  files.  Only  the  owner 
of  the  subtype  (the  Directory  Manager)  shall  be  able  to  write  or  delete  a  direc¬ 
tory  file.  Since  directory  files  are  still  subject  to  mandatory  security  and 
discretionary  access  constraints,  directory  searches  shall  fail  when  the 
appropriate  access  conditions  have  not  been  satisfied. 

When  a  user  process  intends  to  perform  a  directory  operation  that  requires 
writing  on  a  directory  file,  the  process  shall  create  a  child  process  using  the 
Kernel  primitive  K_spavn  and  then  shall  wait  for  the  child  process  to  return. 
The  K_spawn  call  shall  specify  that  the  child  process  shall  be  the  Directory 
Manager  (i.e.  that  the  child  shall  begin  executing  the  Image  of  the  Directory 
Manager).  Through  the  argument  segment,  the  process  shall  specify  the  requested 
directory  operation,  the  pathname  of  the  directory,  and  other  necessary  parame¬ 
ters  (I.e.,  file  pathname,  file  SEID. ) 

3.2.51.2  Processing 

When  invoked,  the  Directory  Manager  process  shall  execute  in  the  discre¬ 
tionary  access  domain  of  the  directory  subtype  owner.  The  Directory  Manager 
shall  obtain  explicit  access  capability  to  the  file  subtype,  directory,  by  per¬ 
forming  a  Kernel  level  open  on  the  subtype  SEID.  The  Directory  Manager  shall 
change  its  access  domain  to  the  real  group  and  user  ID  of  the  invoking  process. 
The  Directory  Manager  shall  open  the  specified  directory  file  at  the  Kernel 
level  supplying  the  open  object  descriptor  returned  from  the  open  on  the  direc¬ 
tory  subtype.  The  Directory  Manager  shall  then  perform  any  one  of  the  following 
operations  as  requested  by  the  invoking  process. 


a.  create  a  new  directory 

b.  make  an  entry  in  an  existing  directory 
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c.  delete  an  entry  from  an  existing  directory 

d.  delete  an  existing  directory 

e.  perform  path  name  interpret  functions. 

Error  conditions  or  return  values  shall  be  sent  to  the  invoking  process  via  IPC 
message.  The  Directory  Manager  process  shall  exit  and  cause  the  invoking  pro¬ 
cess  (waiting  upon  the  death  of  the  child)  to  resume  execution. 

3-2.51.3  Outputs 

The  Directory  Manager  shall  detect  and  report  the  following  exception  con¬ 
ditions  : 


EX:  directory  file  does  not  exist 

EX:  could  not  interpret  directory  pathname  due  to  security  or  discretionary 
access  violation 

EX:  attempt  to  delete  non-empty  directory 
EX:  file  could  not  be  found  in  directory 

Exception  conditions  shall  be  returned  to  the  requesting  process  via  IPC  mes¬ 
sage. 

In  addition,  when  the  Directory  Manager  is  forced  to  violate  the  security 
*-property,  the  Directory  Manager  shall  create  an  audit  record  of  the  event,  and 
send  It  via  an  IPC  message  to  the  Audit  Capture  Process. 

3.2.52  Network  Interface 


The  Emulator  shall  support  the  interface  to  a  modern  computer  network.  The 
protocol  shall  be  the  standard  DOD  Internet  and  Transmission  Protocol  [Postel 
80a]  [Postel  80b] .  Table  I  shows  the  allocation  of  TCP  functions  to  the  three 
CPCI's  which  make  up  KSOS.  In  the  remainder  of  this  paragraph  the  TCP  functions 
performed  by  the  Emulator  are  discussed. 
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Table  I 


TCP 

Functional 

Allocation 

Security 

UNIX 

TCP 

Kernel 

Emulator 

Daemon 

IMP  Supporc 

X 

Rendezvous 

Flow  Control 

X 

Data  Stream 
Integrity: 

Checksum 

Resequence 

X 

X 

Retransmission 

X 

Acknowledge 

X 

Duplicate  Detect 

X 

Routing 

X 

Connection  Alloc. 

X 

Urgent  Processing 

X 

Formatting 

X 

Security  Level 
of  Message 

X 

3.2.52.1  Inputs 

The  inputs  to  the  network  interface  are  the  data  stream(s)  to  and  from  the 
network,  and  control  information.  The  control  information  shall  normally  be 
supplied  as  a  side  effect  of  the  UNIX  calls  to  the  network  (e.g.,  open,  dose, 
read,  and  write).  If  additional  control  information  is  required,  the  stty  and 
gtty  user  calls  may  be  utilized.  The  interpretation  of  the  UNIX  open  call  mode 
argument  shall  be  modified  when  the  "file"  being  opened  is  a  network  logical 
connection.  If  the  mode  is  an  even  number  above  some  defined  minimum,  it  shall 
be  Interpreted  as  the  address  of  a  control  block  in  the  user  address  space  that 
defines  the  parameters  required  for  a  general  network  connection  to  be  esta¬ 
blished.  The  exact  format  of  this  control  block  is  left  to  the  discretion  of 
the  development  contractor.  Modes  0,  1,  and  2  shall  utilize  a  default  set  of 
parameters.  Odd  mode  values  shall  be  considered  to  be  in  error. 
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3.2.52.2  Processing 

3.2.52.2.1  Initiation  of  Connections 


The  Emulator  shall  Initiate  a  connection  by  passing  a  shared  segment  name 
to  the  Network  Daemon  (part  of  the  Non-Kernel  Security-Belated  Software  CPCI) 
using  the  K_post  Security  Kernel  call.  Note  that  if  the  security  levels  of  the 
user  and  the  network  are  such  that  the  requested  communication  cannot  be  esta¬ 
blished,  the  K_post  call  will  fail.  This  shared  segment  shall  be  used  for  all 
subsequent  communication  between  the  Emulator  and  the  Network  Daemon.  The  ini¬ 
tial  contents  of  the  shared  segment  shall  be  the  parameters  needed  by  the  Net¬ 
work  Daemon  to  allocate  the  connection.  The  Network  Daemon  and  the  Emulator 
shall  use  a  protocol  between  themselves  that  assures  that  the  shared  segment 
will  not  become  corrupted. 

3.2.52.2.2  Flow  Control 


The  Emulator  shall  provide  flow  control  on  each  of  the  connections  from  the 
user  process.  In  TCP  this  consists  of  selective  advancing  the  the  windows.  The 
Emulator  shall  be  designed  to  allow  it  to  be  tuned  to  improve  overall  perfor¬ 
mance.  The  tuning  may  be  a  dynamic  adjustment  of  the  window  updating  or  may  be 
a  static  (parameter)  adjustment. 

3.2.52.2.3  Data  Stream  Integrity 

The  Emulator  shall  provide  most  of  the  functionality  in  the  area  of  data 
stream  integrity.  This  shall  include  acknowledgement  of  received  octets 
(bytes),  retransmission  of  unacknowledged  transmissions,  detection  of  duplicate 
octets  in  the  received  stream,  and  resequencing  the  streams.  The  Network  Daemon 
shall  perform  the  checksum  function  on  incoming  and  outbound  data. 

3.2.52.2.4  Urgent  Processing 

(The  subject  of  urgent  processing  is  currently  under  Intense  debate  in  the 
TCP  community.  The  design  requirements  presented  here  should  be  reviewed  in 
light  of  the  latest  conclusions  of  the  community.) 

The  Emulator  should  notify  the  user  that  "urgent"  data  has  not  yet  been 
received  by  him  (the  user).  The  user  should  upon  receipt  of  such  notification 
read  the  data  stream  up  to  the  urgent  pointer.  The  development  contractor  may 
suggest  the  manner  in  which  the  user  is  notified  of  the  existence  of  unprocessed 
urgent  data,  and  the  way  in  which  the  start  of  the  urgent  data  is  communicated 
to  the  user.  The  preferred  mechanism  shall  be  via  the  signal  mechanism. 

3.2.52.2.5  Formatting 

The  Emulator  shall  break  up  the  outbound  data  stream  into  letters  and  seg¬ 
ments.  The  Emulator  may  allow  the  user  to  specify  that  the  end-of-letter  (EOL) 
bit  is  to  be  set  at  some  point  in  the  stream.  In  general,  the  formatting  of  the 
stream  into  segments  and  letters  should  be  transparent  to  the  user  program. 
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3.2.52.3  Outputs 

The  output  of  the  network  interface  function  of  the  Emulator  shall  be  the 
data  streams  to  and  from  the  user  process  and  the  network. 

3. 2 • 53  Special  Requirements 

The  programming  standards  for  the  Emulator  are  discussed  in  the  System 
Specification  (Type  A).  Because  the  Emulator  is  not  trusted  by  the  Security 
Kernel,  the  emphasis  on  provability  of  the  code  is  lessened. 

If  the  Directory  Manager  is  privileged  (so  it  can  create  files  in  direc¬ 
tories  whose  level  is  different  than  that  of  the  process),  it  shall  be  subject 
to  the  same  design  and  construction  requirements  as  other  privileged  software. 

3.2.53.1  Human  Performance 

This  paragraph  is  not  applicable  to  this  specification. 

3.2*53.2  Government  Furnished  Property  List 

The  compiler  for  the  language  used  to  implement  the  Emulator  may  be  fur¬ 
nished  by  the  Government.  The  Government  shall  approve  the  implementation 
language  to  be  used. 

3*  3  Adaptation 

In  general  the  Emulator  should  not  require  adaptation  to  the  environment  of 
a  particular  site.  Because  the  Emulator  is  not  trusted,  it  may  be  modified 
without  affecting  the  security  of  KSOS.  However,  incorrect  modification  of  the 
Emulator  may  adversely  affect  the  UNIX  interface.  The  parameters  which  control 
the  sizes  of  buffer  caches,  and  similar  functions  shall  be  adjustable  by  each 
site  to  tune  the  system. 
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4.  QUALITY  ASSURANCE  PROVISIONS 
4. 1  Introduction 


The  underlying  philosophy  of  KSOS  quality  assurance  Is  to  provide  a  con¬ 
vincing  demonstration  of  the  security  and  completeness  of  the  system.  Testing 
and  quality  assurance  are  a  complement  to  the  formal  verification  aspects  of 
KSOS.  All  testing  on  KSOS  shall  be  conducted  at  the  development  contractor's 
facility. 

KSOS  shail  be  subject  to  the  technical  reviews  and  audit  procedures  of 
MIL -STD-1 52 1A,  Appendices  A-F.  The  following  technical  reviews  and  audits  will 
be  conducted: 


a.  System  Requirements  Review  (Appendix  A) 

b.  System  Design  Review  (Appendix  B) 

C.  Preliminary  Design  Review  (Appendix  C) 

d.  Critical  Design  Review  (Appendix  D) 

e.  Functional  Configuration  Audit  (Appendix  E) 

f.  Physical  Configuration  Audit  (Appendix  F) 

The  Critical  Design  Review  shall  include  a  review  of  any  mathematical 
proofs  showing  that  the  design  meets  the  requirements  of  the  Government  approved 
DoD  security  model. 

The  Functional  Configuration  Audit  shall  be  the  vehicle  for  the  formal 
review  of  the  design  versus  its  specifications.  The  Physical  Configuration 
Audit  shall  be  the  vehicle  for  the  formal  review  of  the  "as  built"  computer  pro¬ 
grams  versus  both  their  design  and  their  supporting  documentation.  In  addition, 
the  Physical  Configuration  Audit  shall  verify  that  the  implementation  require¬ 
ments  of  the  Type  A  System  Specifications,  have  been  met.  Both  audits  shall 
include  review  of  any  relevant  mathematical  proofs  of  correctness. 

4.1.1  Category  I  Testing 

The  development  contractor  shall  establish  test  plans  to  demonstrate  that 
all  the  requirements  of  Section  3  have  been  met.  These  tests  shall  be  designed 
to  exercise  all  the  interface  options  for  each  function.  To  the  extent  feasi¬ 
ble,  the  tests  shall  exercise  all  combinations  of  options.  The  tests  shall 
include  sequences  intended  to  fail,  such  as  attempts  to  violate  the  system's 
security  rules  or  to  use  unacceptable  combinations  of  options.  Government 
approval  of  all  test  plans  is  required. 

The  general  mechanism  for  assuring  that  the  requirements  of  Section  3  have 
been  met  shall  be  a  comparison  of  the  system  "state"  before  and  after  the  func¬ 
tion  has  been  invoked.  To  ensure  repeatability  all  testing  shall  be  automated 
if  possible.  Such  automation  may  include  (but  is  not  limited  to)  shell  scripts. 
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test  programs,  and  terminal  emulation  by  another  computer  system. 

4.1.2  Category  II  Testing 

In  addition  to  the  tests  described  above,  the  entire  RSOS  system  shall  be 
subject  to  on  overall  system  test.  These  Category  II  tests  shall  be  carried  out 
in  accordance  with  the  provisions  of  the  development  contract,  but  should 
Include  at  least  one  test  with  at  least  ten  (10)  terminals  and  a  network  connec¬ 
tion  simultaneously  active.  The  Category  II  tests  should  exercise  the  entire 
system  by  simulating  a  typical  user  load.  The  Category  II  testing  should  be 
automated  as  much  as  possible  through  the  use  of  shell  scripts,  test  load  pro¬ 
grams,  and  terminal  emulation  by  another  computer  system. 

Table  II  -  Quality  Assurance 

Assurance  techniques: 

NA  Not  Applicable 

V  Verification 

F  Formal  Specification 

T  Testing 

D  Demonstration 

A  Analysis 

I  Inspection 

Applicable  test  types: 

1  Module  level  testing 

2  Integration  testing 

3  Acceptance  testing 


Requirement 
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PREPARATION  FOR  DELIVERY 

This  section  Is  not  applicable  to  this  specification* 
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6.  NOTES 


This  section  Is  not  applicable  to  this  specification. 
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Kernellzed  Secure  Operating  System  (KSOS):  Non- 
Kernel  Security  Related  Software  Computer 
Program  Development  Specification  (Type  B5) 


1.  SCOPE 


1.1  Identification 


This  specification  establishes  the  performance,  design,  development  and 
test  requirements  for  the  Non-Kernel  Security  Related  Software  Computer  Program 
Configuration  Item  (CPCI)  which  is  part  of  the  Kernellzed  Secure  Operating  Sys¬ 
tem  (referred  to  as  "KSOS").  KSOS  provides  a  provably  secure,  resource-sharing 
operating  system  compatible  with  the  standard  user  environment  provided  by  UNIX, 
as  described  by  [Thompson  75]  and  [Ritchie  74].  The  Non-Kernel  Security  Related 
Software  provides  those  functions  which  are  needed  by  the  system  for  continued 
operation  and  maintenance,  and  which  are  not  part  of  the  Security  Kernel  CPCI. 

1.2  Functional  Summary 

The  Non-Kernel  Security  Related  Software  is  a  collection  of  autonomous  sub¬ 
systems;  some  of  which  execute  with  extraordinary  privilege  (l.e.  more  privilege 
than  is  afforded  to  user  programs)  to  provide  essential  services  to  the  system. 
Such  services  include,  but  are  not  limited  to,  the  following: 

*  Secure  User  Services :  those  services  Invoked  by  users  which  require  a 
trusted  path  from  the  user  to  the  service  (e.g.,  the  login  process). 

*  System  Operation  Services;  those  functions  essential  to  the  operation  of  a 
KSOS  system  (e.g.,  the  Process  Bootstrapper ) . 

*  System  Maintenance  Services;  those  functions  needed  for  continued  operation 
and  maintenance  of  a  KSOS  system,  such  as  dump  and  restore  of  file  systems. 

♦  System  Administrator  Services;  those  functions  needed  to  support  the  admin¬ 
istrative  operation  of  the  system,  such  as  the  adding  and  deleting  of 
users . 

The  remainder  of  this  specification  is  organized  as  follows: 

4  Section  2  contains  the  references 

■*  Section  3  contains  the  requirements  for  the  CPCI 

♦  Section  4  contains  the  quality  assurance  provisions  for  the  CPCI 

♦  Sections  5  and  6  are  not  applicable  and  are,  therefore  not  present. 
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1. 3  Terminology 

The  language  used  throughout  this  specification  attempts  to  conform  to  the 
guidelines  of  Section  3-2.3  of  MIL-STD-490.  In  particular,  the  word  "shall" 
means  that  the  specification  expresses  a  provision  that  is  binding.  The  words 
"should"  and  "may"  mean  that  the  specification  expresses  a  provision  which  is 
non-mandatory.  The  word  "will"  is  used  to  express  a  declaration  of  purpose  on 
the  part  of  the  Government. 

KSOS  shall  support  the  mandatory  DoD  security  policy  of  DoD  Directive 
5200. I -R  which  is  embodied  in  a  Government  approved  mathematical  model.  [Verif 
78]  Proofs  of  the  system's  security  properties  shall  be  in  terms  of  this  model. 
KSOS  shall  provide  a  minimum  of  eight  (8)  hierarchical  security  classifications 
categories  (or  simply  security  categories)  and  a  minimum  of  thirty-two  (32) 
mutually  independent  security  compartments.  The  security  Categories  shall  be 
such  that 


UNCLASSIFIED  <  CONFIDENTIAL  <  SECRET  <  TOP  SECRET 


Where  "<"  is  defined  in  accordance  with  the  requirements  of  DoD  5200. I-R.  One 
security  compartment  shall  be  reserved  for  read  protection  of  system  data  bases 
and  programs.  This  compartment  shall  be  called  the  "system"  compartment. 

KSOS  shall  provide  for  Kernel -enforced  integrity.  Integrity  Is  defined  as 
the  formal  mathematical  dual  of  security  (Biba  75].  At  least  four  (4)  hierarchi¬ 
cal  Integrity  classifications  categories  (or  simply  integrity  categories)  shall 
be  provided  in  KSOS.  The  integrity  Categories  include  at  least  the  following 
three  classification  categories: 


USER  <  OPERATOR  <  ADMINISTRATOR 


Although  there  is  no  immediate  requirement  for  integrity  compartments,  the 
development  contractor  should  include  provisions  to  ease  their  later  inclusion. 

For  the  remainder  of  this  specification,  the  term  "security  level"  means 
the  combination  of  a  security  category  and  a  set  of  security  compartments  (which 
may  be  null).  The  term  "integrity  level"  means  the  combination  of  an  integrity 
category,  and  a  (presently  always  null)  set  of  Integrity  compartments.  The  term 
"level"  (or  access  level)  means  the  security  and  integrity  level;  i.e»,  the  com¬ 
bination  of  a  security  category,  a  set  of  security  compartments  (which  may  be 
null),  an  integrity  category,  and  a  (presently  always  null)  set  of  integrity 
compartments.  The  "access  matrix"  defines,  for  a  particular  user  or  group,  the 
combination  of  the  maximum  security  level  permitted  for  that  user  or  group,  all 
security  compartments  to  which  that  user  or  group  has  access,  the  maximum 
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integrity  level  for  that  user  or  group,  and  all  integrity  compartments 
(presently  always  null)  to  which  that  user  or  group  has  access. 

In  a  secure  system,  it  is  necessary  to  have  processes  external  to  the  ker¬ 
nel  which  perform  security  critical  functions.  These  processes  have  come  to  be 
called  "trusted  processes".  In  KSOS,  there  is  a  refinement  in  this  terminology. 
As  Figure  1-1  shows  there  are  subdivisions  of  the  software  inside  the  security 
perimeter.  Some  of  the  processes  are  "privileged",  in  other  words,  they  may 
violate  one  or  more  of  the  security  rules  enforced  by  the  Kernel.  These 
processes  must  be  designed  and  implemented  with  the  same  care  and  thoroughness 
as  the  Kernel  itself.  Section  3. 1.1. 2. 4. 4  presents  the  privileges  which  may  be 
afforded  processes. 

A  second  subdivision  has  been  termed  "responsible"  processes.  These 
processes  are  not  privileged  to  violate  any  of  the  Kernel's  rules,  but  which 
are,  nonetheless,  important  to  the  overall  security  of  the  system.  Examples  of 
responsible  processes  include  the  Secure  Mail  facility  and  the  processes  which 
manipulate  the  data  bases  describing  the  users'  security  and  integrity  permis¬ 
sions  (the  "access  matrix").  These  processes  must  also  be  carefully  designed 
and  implemented,  but  do  not  require  formal  specification  or  verification. 
Because  they  do  perform  security  related  functions,  they  cannot  include 
untrusted  components  (e.g.  the  UNIX  Emulator). 

The  third  subdivision  is  the  "encapsulated  utilities"  (EU  in  the  figure). 
These  are  self-contained  functions  to  which  the  user  simply  supplies  parameters. 
The  encapsulated  utilities  are  not  privileged  to  violate  Kernel  rules  and  do  not 
affect  the  security  of  users.  The  chief  function  in  the  encapsulated  utilities 
is  system  generation. 
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2.  APPLICABLE  DOCUMENTS 

The  following  documents,  of  exact  issue  shown,  form  a  part  of  this  specifi¬ 
cation  to  the  extent  specified  herein.  In  the  event  of  a  conflict  between  the 
referenced  documents  and  the  contents  of  this  specification,  this  specification 
shall  be  considered  a  superseding  requirement-  In  the  text,  references  to  these 
documents  are  in  the  form  [Name  date],  e.g.  [Biba  75]. 

2. 1  Government  Documents 

2.1.1  Directives.  Manuals  and  S tandards 

a.  DoD  5200. 1-R  Information  Security  Program  Regulation 

b.  DoD  5200.28  Security  Requirements  for  Data  Processing  (ADP) 

c-  DoD  5200. 28-M  ADP  Security  Manual 

d.  MIL-STD-483  Configuration  Management 

e.  MIL-STD-490  Specification  Practices 

f.  MIL-STD-1521A  Technical  Reviews  and  Audits 
2. 1 • 2  Reports 

a.  [A-Specs  78]  "KSOS  System  Specification  (Type  A)",  WDL-TR7808  Revision  1, 
Ford  Aerospace  and  Communications  Corporation,  Palo  Alto,  CA  (July  1978). 

b.  [Bell  and  LaPadula  73]  Bell,  D.E.  and  LaPadula,  L.J.,  "Secure  Computer  Sys¬ 
tems",  ESD-TR-73-278 ,  Volume  I-III,  MITRE  Corporation,  Bedford,  MA 
(November  1973  -  June  1974). 

c.  [Biba  75]  Biba,  K. J.,  "Integrity  Considerations  for  Secure  Computer  Sys¬ 
tems",  MTR-3153,  MITRE  Corporation,  Bedford,  MA  (June  1975). 

d.  [Emulator  78]  "KSOS  Computer  Program  Development  Specification  (Type  B5): 
UNIX  Emulator",  WDL-TR7932,  Ford  Aerospace  and  Communications  Corporation, 
Palo  Alto,  CA  (September  1978). 

e.  [Kernel  78]  "KSOS  Computer  Program  Development  Specification  (Type  B5): 
Security  Kernel",  WDL-TR7932,  Ford  Aerospace  and  Communications  Corpora¬ 
tion,  Palo  Alto,  CA  (September  1978). 

f.  [Verlf  78]  "KSOS  Verification  Plan”,  WDL-TR7809,  Ford  Aerospace  and  Commun¬ 
ications  Corporation,  Palo  Alto,  CA  (March  1978). 

g.  [Walter  et  al.  74]  Walter,  K.G.  et  al.,  "Primitive  Models  for  Computer 
Security",  ESD-TR-74-1 1 7,  Case  Western  Reserve  University,  Cleveland,  OH 
(January  1974). 
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2. 2  Non-Governnent  Documents 

a.  [BBN  75]  "interface  Message  Processor,  Specifications  for  the  Interconnec¬ 
tion  of  a  Host  and  an  IMP",  Report  1822,  Bolt  Beranek  and  Newman  Inc.,  Cam¬ 
bridge,  MA,  (December  1975). 

b.  [Holmgren  et  al.  77]  Holmgren,  S.F.,  Healv,  D.C.,  Jones,  P.B.  and 
Kasprzycki,  E.,  "Illinois  Inter-Process  Communication  Facility  for  UNIX", 
CAC  Technical  Memorandum  84,  CCTC-WAD  Document  7507,  Center  for  Advanced 
Computation,  University  of  Illinois  at  Urbana-Champaign,  Urbana,  IL  (April 
1977). 

c.  [Lampson  73]  Lampson,  B.,  "A  Note  on  the  Confinement  Problem",  CACM,  Volume 
16,  Number  10,  pp  613  -  615  (October  73). 

d.  [Lipner  75]  Lipner,  S.B.,  "A  Comment  on  the  Confinement  Problem",  Proc. 
Fifth  Symposium  on  Operating  Systems  Principles,  ACM  SIGOPS  Review,  Volume 
9,  Number  5,  pp  192  -  196  (19-21  November  1975). 

e.  [Nemeth  et  al.  77]  Nemeth,  A.G.,  Sunshine,  C.,  Zucker,  S.  and  Tepper , 
"Progress  Towards  a  DeFacto  DoD  UNIX  Inter-Process  Communication  Standard", 
Working  Paper,  (May  1977).  (Available  from  the  authors.) 

f.  [Parnas  72]  Parnas,  D.L.,  "A  Technique  for  Software  Module  Specification 
with  Examples",  CACM,  Volume  15,  Number  5,  pp  330  -  336  (May  1972). 

g.  [Postel  78a]  Postel,  J.B.,  "Internetwork  Protocol  Specification",  Version  4 
,  Information  Sciences  Institute,  University  of  Southern  California,  Marina 
del  Rey,  CA  (February  1979). 

h.  [Postel  78b]  Postel,  J.B.,  "Specification  of  Internetwork  Transmission  Con¬ 
trol  Protocol  -  TCP",  Version  4  (draft).  Information  Sciences  Institute, 
University  of  Southern  California,  Marina  del  Rey,  CA  (February  1979). 

i.  [Roubine  and  Robinson  77]  Roubine.O.,  L. Robinson,  Special  Reference  Manual, 
3rd  ed..  Technical  Report  CSG-45,  SRI  International,  Menlo  Park,  CA  (Janu¬ 
ary  1977). 

j.  [Sunshine  77]  Sunshine,  C.,  "Interprocess  Comnunication  Extensions  for  the 
UNIX  Operating  System:  I  Design  Considerations",  R-2064/1-AF,  PAND  Corpora¬ 
tion, 

k.  [Zucker  77]  Zucker,  S.,  "Interprocess  Communication  Extensions  for  the  UNIX 
Operating  System:  II  Implementation",  R-2064/2-AF,  RAND  Corporation,  Santa 
Monica,  CA  (June  1977). 

2- 3  Other  References  Not  Part  of  This  Specification 

a.  [Thompson  75]  Thompson,  K.  and  Ritchie,  D.M.,  "UNIX  Programmer's  Manual", 
Sixth  Edition,  Western  Electric  Corporation,  Greensboro,  NC  (May  1975). 

b.  [Ritchie  74]  Ritchie,  D.M.  and  Thompson,  K.,  "The  UNIX  Timesharing  System", 
CACM,  Volume  17,  Number  5,  pp  365  -  375  (May  1974). 
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c. 


[UNIX  75]  "UNIX  Program  Listings",  Version  6.0,  Western  Electric  Corpora¬ 
tion,  Greensboro,  NC  (May  1975). 
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3.  REQUIREMENTS 


The  Non-Kernel  Security  Related  Software  shall  provide  those  security 
relevant  functions  which  are  not  allocated  to  the  Security  Kernel  CPCI.  Certain 
functions  of  the  CPCI  may  be  privileged  to  violate  one  or  more  of  the  Security 
rules  of  the  Security  Kernel  in  providing  overall  system  security-  These 
privileged  functions  and  the  rules  which  they  violate  are  identified  in  this 
section-  The  privileged  runctions  must  be  implemented  with  the  same  precision 
and  thoroughness  as  the  Security  Kernel-  The  System  Specifications  (Type  A)  [A- 
Specs  78]  for  KSOS  present  the  requirements  and  constraints  for  the  design  and 
the  implementation.  Non-Kernel  Security  Related  Software  shall  operate 
correctly  without  modification  on  all  hardware  configurations  defined  in  the 
System  Specification  for  KSOS. 

Several  of  the  functions  described  in  this  section  require  constraints  on 
their  user;  e-g-,  to  use  some  of  these  programs,  the  user  must  be  at  a  certain 
integrity  level  or  higher.  These  programs  must  be  run  in  the  "SYSTEM"  compa' 
ment  which  is  reserved  tor  such  programs  and  data  bases-  These  steps  assure 

that  the  executable  images  and  data  bases  remain  untampered  with  and  chat  th 

programs  cannot  be  invoked  successfully  by  unauthorized  users.  For  compactni  -i , 
some  of  the  functions  are  described  as  being  available  only  to  the  System  Opera¬ 
tor,  which  means  a  user  running  at  OPERATOR  level  or  higher  level  and  in  the 

"system"  security  compartment- 

3- 1  Computer  Program  Definition 

3-1-1  Interface  Requirements 

The  Non-Kernel  Security  Related  Software  may  utilize  the  Security  Kerne,: 
interface  and,  in  some  cases,  may  use  the  UNIX  interface  provided  h»  UNT'" 
Emulator-  These  two  interfaces  are  specified  in  the  companion  Type  3.  :pecifi~ 
cations  for  these  CPCI's- 

3. 1.1.1  Interface  Block  Diagram 

Figure  3-1  shows  the  relationship  of  the  functional  components  of  KSOS. 


1 

User  Programs |  untrusted 

•  1 

USER  MODE 

1 

(may  include  j  NKSR 

•  I 

1 

I 

Kernel  calls) | 

1 

•  1 

SUPERVISOR 

! 

“1  1 

MODE 

1 

UNIX  EMULATOR 

| trusted  NKSR  I 

1  _.! 

KERNEL  MODE 

1 

SECURITY  KERNEL 

(NKSR;  Non-Kernel  Security  Related  Software) 
Figure  1-2.  Functional  Components  of  KSOS 
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The  call  from  domains  of  lesser  privilege  to  those  of  greater  privilege  shall  be 
mechanized  by  means  of  an  inter-domain  call.  In  the  PDP-11 /70  implementation  the 
TRAP  and  IOT  instructions  shall  be  used  by  user  programs  to  call  the  UNIX  Emula¬ 
tor.  The  EMT  instruction  shall  be  used  by  user  programs  and  the  Emulator  to 
call  upon  the  Kernel. 

It  should  be  noted  that  no  privileged  functions  may  use  the  Emulator,  since 
the  Emulator  is  not  trusted.  Those  functions  in  the  Mon-Kernel  Security  Related 
Software  which  are  not  privileged  (e-g.,  the  Secure  Mail  spooler)  may  use  the 
Emulator . 

3 . 1 . 1 . 2  Detailed  Interface  Definition 
3. 1.1. 2.1  Secure  User  Services 

The  Secure  User  Services  class  of  Non-Kernel  Security  Related  Software  con¬ 
sists  of  those  functions  which  require  a  secure  path  to  and  from  the  user,  such 
as  the  login  process.  In  general,  the  functions  which  require  such  a  secure 
path  are  those  in  which  the  user  may  be  supplying  raw  passwords  or  the  names  of 
objects  to  be  manipulated  in  a  trusted  way  such  as  changing  the  security  of  an 
ob j  ect . 


3. 1*1.2. 1.1  Secure  Initiator 


The  Secure  Initiator  shall  be  invoked  by  the  Initial  Process  when  the  sys¬ 
tem  is  booted.  The  Secure  Initiator  shall  spawn  off  the  Audit  Capture  Process 
(ACP),  initialize  various  objects,  and  executed  a  file  of  commands  similar  to 
the  rc  files  on  UNIX.  The  Initiator  shall  also  spawn  one  Secure  Server  process 
(SSP)  for  each  configured  terminal  in  the  system.  A  data  base  containing  a  list 
of  the  configured  terminals  paired  with  the  appropriate  Secure  Servers  id 
created  by  the  Secure  Initiator. 

3. 1.1. 2. 1.2  Secure  Server 


One  Secure  Server  process  shall  be  present  for  each  configured  terminal  in 
a  KSOS  system.  The  Secure  Server  shall  receive  commands  from  the  user  at  the 
terminal  via  the  secure  path,  and  shall  spawn  processes  on  behalf  of  the  user  to 
carry  out  these  commands. 

Each  terminal  in  the  system  shall  logically  consist  of  a  set  of  mutually 
exclusive  logical  data-paths.  Only  one  path  shall  be  active  at  any  one  time-  All 
terminal  input  shall  be  directed  to  the  currently  active  path,  and  an  attempt  to 
read  or  write  on  a  path  other  than  the  active  path  shall  cause  the  requesting 
process  to  become  blocked.  One  path  shall  be  denoted  as  the  secure  path,  and 
shall  be  used  exclusively  by  the  Secure  Server.  The  secure  attention  character 
shall  cause  the  kernel  to  select  the  secure  path  as  the  active  path.  Selection 
of  an  alternative  terminal  path  shall  be  performed  by  a  SET_PATH  operation  of 
the  K_device_f unction  call.  This  shall  be  a  privileged  operation  whose  use  is 
restricted  to  the  Secure  Server. 

On  receipt  of  a  secure  attention  character,  the  Secure  Server  shall  prompt 
for  input  from  the  terminal.  The  Secure  Server  shall  interpret  the  input  as  a 
request  for  a  Secure  User  Service.  If  the  user  is  authorized  to  use  the  service. 
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the  service  shall  be  performed,  either  by  Lhe  Server,  or  by  spawning  a  process 
to  perform  the  service  on  behalf  of  the  user- 

Some  Secure  User  Services  shall  be  capable  of  changing  their  security  and 
integrity  levels,  and  real  owner  (user  ID  and  group  ID)  while  running.  This 
capability  provides  the  mechanism  necessary  to  perform  in  a  controlled  manner 
those  user  requests  which  either  change  Lhe  user's  level  or  which  require 
actions  to  be  performed  at  another  level-  Because  the  Server  has  access  to  the 
user's  access  matrix  it  is  able  to  verify  the  user's  access  level  restrictions 
before  pertorming  any  requested  functions.  Additionally,  certain  Secure 
processes  can  access  restricted  databases  which  system  users  are  unable  to 
access.  These  processes  allow  for  the  updating  of  these  databases  in  a  con¬ 
trolled  and  audited  manner. 

The  Secure  User  Services  under  the  direction  of  the  Secure  Server  shall 
provide  for  authentication  of  users,  control  of  user  access  levels,  password 
modification,  file  access  modification,  and  the  spawning  of  level  preserving 
copy  and  print  functions. 

3. 1.1.2. 1.3  Access  Authentication  Functions 

A  set  of  Lhe  Secure  User  Services  known  as  the  Access  Authentication  Func¬ 
tions  shall  Service  all  user  requests  for  login,  changing  group,  changing  user 
access  level  (access  level  includes  security  and  integrity  level),  and  logout. 

3.  1 . 1 . 2- 1 . 3.  1  Processing  Operator  Requests 

The  login  and  logout  functions  shall  accept  the  following  commands  from  the 
System  Operator  to  control  system  access- 

a.  Logout  a  Terminal  -  Requests  to  logout  a  terminal  shall  be  handled  in  the 
same  manner  as  if  requested  by  the  user-  Whether  or  not  the  terminal  was 
logged  in,  the  terminal  mode  shall  be  set  to  the  values  listed  for  it  in 
the  Terminal  Profile  Data  Base*  This  provides  a  mechanism  to  regain  con¬ 
trol  of  a  terminal  in  an  incorrect  mode. 

b.  Logout  All  Terminals  -  A  check  shall  be  made  of  all  terminals  configured  in 
the  Terminal  Profile  Data  Base  and  a  logout  shall  be  performed  on  all  ter¬ 
minals  except  the  terminal  designated  as  the  operator's  console. 

c.  Lock  a  Terminal  -  This  command  shall  prevent  logins  on  the  designated  ter¬ 
minal.  This  function  will  not  force  a  logout  on  a  terminal  that  is  logged 
in  when  the  command  is  issued,  although  the  System  Operator  may  do  so  with 
another  command  if  desired. 

d.  Lock  All  Terminals  -  This  command  shall  prevent  login  on  all  terminals 
except  the  operator's  console*  However,  terminals  already  logged  in  will 
not  be  logged  out. 

e.  Unlock  a  Terminal  -  This  command  shall  allow  logins  on  the  designated  ter¬ 
minal. 
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f.  Unlock  All  Terminals  -  T;iis  command  shall  allow  logins  on  all  terminals. 

g.  Set  System  Security  Level  -  This  command  shall  set  the  maximum  security 
level  permitted  on  the  system  and  this  maximum  level  shall  be  checked  when 
a  user  makes  a  change  level  or  login  request.  It  shall  not  affect  the  level 
of  any  user  logged  in  when  the  command  is  issued.  If  the  system  level  is 
being  lowered,  the  System  Operator  may  wish  to  logout  users  above  that 
level,  or  he  (she)  may  simply  notify  them  to  change  their  levels  or  logout 
as  soon  as  possible,  forcing  a  logout  only  if  they  are  unresponsive.  It 
shall  not  be  possible  to  raise  the  system  level  above  the  system  maximum 
level  defined  in  the  System  Database. 

3. 1.1. 2. 1.4  Password  Modification  Function 


The  Password  Modification  Function  shall  allow  a  user  to  change  his  login 
password.  It  shall  also  allow  the  user  designated  as  the  Group  Administrator  in 
the  Group  Access  Authentication  Database  to  change  the  group  password  for  that 
group.  The  Password  Modifier  shall  not  allow  a  user  to  change  the  password  of 
another  user.  If  a  user  is  unable  to  login  because  of  a  bad  password  he  must 
request  the  System  Administrator  to  change  it  to  a  temporary  password,  allowing 
him  to  login  and  enter  a  new  password. 

3. 1.1. 2. 1.5  File  Access  Modification  Function 


The  File  Access  Modification  Function  shall  allow  a  user  to  modify  access 
levels  including  security,  integrity,  and  discretionary  access  levels  on  files 
which  he  owns.  It  shall  not  allow  him  to  grant  any  special  privileges  to  his 
files. 


3. 1.1.2. 1.6  Level  Preserving  Copy  Function 

The  Secure  User  Services  shall  provide  facilities  to  copy  files  while  main¬ 
taining  their  security  and  integrity  levels  without  the  requirement  of  the  user 
being  at  the  same  level  as  the  file.  Since  objects  created  by  processes  are 
always  created  at  the  access  level  at  which  the  process  is  running,  normal 
copies  would  often  result  in  the  unnecessary  upgrading  of  files.  All  security 
checks  shall  remain  in  effect  for  this  type  of  copy.  The  test  to  determine  if  a 
Level  Preserving  Copy  will  be  successful  is  to  determine  if  the  user  would  be 
able  to  change  his  level  to  the  level  of  the  file  and  then  attempt  do  a  normal 
copy . 


If  the  above  test  is  successful  the  Secure  Server  shall  spawn  a  standard 
copy  at  the  level  of  the  file  to  be  copied  and  with  the  requesters  owner  and 
group.  The  copy  may  still  fail  if  the  copy  process  is  unable  to  open  the  input 
file  or  create  the  output  file  because  discretionary  access  or  other  con¬ 
straints. 


3 . 1 . 1 . 2 . I . 7  Level  Preserving  Print  Function 

The  Level  Preserving  Priat  Function  operates  in  the  same  manner  as  the 
Level  Preserving  Copy  Function  except  that  the  output  is  spooled  for  printing  on 
the  line  printer. 
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3- 1- 1.2.2  System  Operation  Services 

The  System  Operation  Services  class  of  Mon-Kernel  Security  Related  Software 
shall  consist  of  those  functions  which  are  essential  to  the  continuing  operation 
of  the  system.  These  functions  shall  have  separate  interfaces  and,  in  general, 
are  independent  of  each  other. 

3. 1.1. 2. 2.1  Network  Daemon 


The  Network  Daemon  shall  multiplex  and  demultiplex  the  data  streams  to  and 
from  the  computer  network.  The  Network  Daemon  shall  be  privileged  to  allow  it  to 
handle  a  network  that  can  support  communications  at  varying  security  levels. 
The  Network  Daemon  shall  have  three  main  interfaces: 

a.  the  Interface  Message  Processor  (IMP)  (or  equivalent)  interface 

b.  the  Daemon  Control  Interface 
C.  the  Network  User  Interface 

3. 1.1. 2. 2. 1.1  IMP  Interface 

The  Network  Daemon  shall  communicate  with  the  network  via  the  IMP  interface 
that  is  provided  by  the  Security  Kernel.  This  IMP  interface  shall  appear  to  the 
Network  Daemon  as  a  device.  For  functions  not  common  to  all  devices,  the 
K_device_f unction  Kernel  call  shall  be  employed.  The  main  part  of  the  IMP  inter¬ 
face,  of  the  Network  Daemon  shall  be  the  mechanization  of  the  Host-to-Imp  Proto¬ 
col  as  defined  by  [BBN  75]  (or  other  equivalent  interfaces  as  specified  by  the 
Government  in  the  development  contract)  and  the  mechanization  of  the  Internet¬ 
work  Datagram  Layer  [Postel  78a]  of  the  Transmission  Control  Protocol  (TCP). 

3.  1. 1. 2. 2. 1. 2  Daemon  Control  Interface 


The  Daemon  Control  Interface  shall  be  the  mechanism  by  which  the  System 
Operator  (or  other  authorized  user)  controls  the  state  of  the  Network  Daemon, 
and  thereby  the  state  of  all  network  connections.  The  Daemon  Control  Interface 
shall  be  mechanized  by  means  of  inter-process  conmunication  from  another  process 
running  at  the  OPERATOR  or  higher  integerity  level.  The  following  Daemon  Con¬ 
trol  commands  shall  be  provided  (the  development  contractor  may  extend  or  modify 
this  list  to  suit  the  needs  of  a  particular  Network  Daemon  implementation): 

a.  Reset  Daemon  -  shall  return  the  Network  Daemon  to  its  initial  state.  This 

function  shall  include  destroying  all  logical  connections,  transmitting  any 
required  resetting  messages  to  remote  hosts,  and  similarly  informing  the 
local  end  of  all  network  connections.  It  should  be  used  only  in  cases 
where  the  Network  Daemon  has  become  hopelessly  confused. 

b.  Reset  Host  -  shall  return  the  state  of  a  particular  remote  host  to  Its  ini¬ 
tial  state,  destroying  all  open  connections  to  that  host. 

c.  Abort  Connection  -  shall  destroy  a  particular  connection.  Both  the  local 

and  remote  ends  of  the  connection  shall  be  informed  of  the  aborting  of  the 

connection  via  the  normal  Network  Daemon  status  returns. 
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d.  Dump  Status  -  shall  cause  the  Network  Daemon  to  dump  its  internal  status 
Information  to  a  file.  Because  the  status  of  the  Daemon  may  involve  connec¬ 
tions  of  differing  security  levels,  the  classification  of  the  status  file 
shall  be  system  high. 

3. 1. 1.2. 2. 1.3  User  Interface 

The  User  Interface  to  the  Network  Daemon  shall  be  via  inter-process  commun¬ 
ication  and  shared  segments.  The  bulk  of  the  TCP  functions  shall  be  performed 
in  the  UNIX  Emulator  [Emulator  78].  Thus,  a  UNIX  user-mode  program  would  not 
communicate  directly  with  the  Network  Daemon.  Rather,  the  system  Calls  from  the 
user-mode  program  shall  be  interpreted  by  the  UNIX  Emulator  and  transformed  into 
inter-process  communication  messages  to  and  from  the  Network  Daemon.  The  user 
shall  initiate  network  communications  using  the  UNIX  "open"  system  call.  To 
provide  the  additional  Information  needed  to  open  a  network  connection,  the 
"mode"  argument  shall  be  subject  to  an  extended  interpretation.  If  the  "mode" 
argument  is  even  and  greater  than  some  defined  constant  and  the  "open"  is  for  a 
network  connection,  then  the  argument  shall  be  interpreted  as  the  address  of  a 
control  block.  The  exact  format  of  the  control  block  is  left  to  the  discretion 
of  the  development  contractor. 

The  UNIX  Emulator  shall  interface  with  the  Network  Daemon  in  the  following 
manner.  The  opening  of  connections  shall  be  accomplished  by  the  transmission  of 
IPCs  to  the  daemon.  The  IPCs  shall  specify  the  identity  of  a  sharable  segment 
for  subsequent  data  transfers  between  the  emulator  and  the  daemon.  Completion 
of  a  connection  open  request  by  the  daemon  shall  be  notified  to  the  emulator  by 
an  IPC  message  containing  status  Information.  Reading  to  and  writing  from  the 
network  shall  be  accomplished  by  passing  the  data  via  the  shared  segment,  with 
control  information  for  each  transfer  being  passed  in  IPC  messages.  Multiple 
connections  from  a  particular  user  may  be  multiplexed  over  the  same  shared  seg¬ 
ment.  The  UNIX  Emulator  and  the  Network  Daemon  shall  obey  a  protocol  that 
preserves  the  integrity  of  the  shared  segment  (for  example,  the  protocol  could 
ensure  that  they  both  do  not  try  to  write  the  segment  simultaneously,  although 
other  less  restrictive  protocol  possibilities  exist). 

To  facilitate  the  construction  of  network  applications  which  do  not  include 
the  UNIX  Emulator,  the  TCP  handling  in  the  Emulator  shall  be  designed  to  be  as 
separate  as  possible  from  the  remainder  of  the  Emulator. 

3. 1.1. 2. 2. 2  Line  Printer  Spooling 

KSOS  shall  provide  a  secure  mechanism  for  spooling  output  to  the  printer. 
The  mechanism  shall  be  secure  in  the  sense  that  users  cannot  alter,  view,  or 
delete  the  spooled  output  of  other  users.  In  addition,  the  appropriate  headers 
and  footers  shall  be  placed  on  the  printed  output*  Finally,  a  record  of  the 
creation  of  classified  printer  output  shall  be  generated.  There  are  two  inter¬ 
faces  to  the  Spooler: 

a.  The  User  Interface  -  similar  to  the  interface  to  the  present  UNIX  spooler 
(/bin/opr  and  /lib/lpr). 

b.  The  Line  Printer  Daemon  Control  Interface  -  allows  a  System  Operator  (or 
other  privileged  user)  to  control  the  Daemon  (de-spooler). 
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3. 1. I.2.2.2. 1  User  Interface 


The  interface  to  the  Line  Printer  Spooler  shall  allow  the  user  to: 

a.  Print  multiple  copies  of  a  file  (or  files) 

b.  Allow  the  user  to  specify  an  alternate  heading  on  the  burst  pages 

The  User  Interface  shall  be  implemented  as  arguments  to  the  Spooler  program, 
using  the  standard  UNIX  argument  passing  conventions. 

3.  1 .  1 . 2. 2 . 2 . 2  Line  Printer  Daemon  Control  Interface 

The  Line  Printer  Daemon  Control  Interface  shall  be  via  inter-process  com¬ 
munication  and  shall  allow  the  System  Operator  (or  other  privileged  users)  to: 

a.  Abort  the  printing  of  a  file 

b.  Backup  and  reprint  a  page  (for  paper  changes) 

3.  1.1. 2.2. 3  As sign /Deassign 

The  Assign/Deassign  functions  shall  allow  users  to  become  owners  of  certain 
physical  devices  without  having  the  privilege  to  do  general  ownership  changing. 
Assign  shall  only  allow  the  assignment  of  devices  from  a  pool  of  free  devices. 
It  shall  not  be  possible  to  assign  a  device  that  is  presently  in  use  or  which  is 
reserved  for  the  system  or  another  user* 

Assign  and  Deassign  shall  be  spawned  through  the  Secure  Server  mechanism. 
The  user's  interface  to  Assign  shall  consist  of  specifying  the  device(s)  to  be 
assigned  .  The  user  interface  to  Deassign  shall  consist  of  specifying  the 
device(s)  to  be  deassigned.  The  System  Operator  shall  be  able  to  force  a  device 
to  be  deassigned. 

The  ability  to  assign  ownership  of  a  physical  device  such  as  a  tape  or  disk 
drive  to  a  user  shall  allow  the  user  to  use  that  device  to  access  his  media 
without  risk  of  unauthorized  access  by  other  users.  The  user  should  assign  a 
device  before  physically  placing  his  media  in  it.  This  mechanism  shall  protect 
media  from  unauthorized  access  between  the  time  the  media  is  physically  mounted 
and  the  time  the  user  process  open  the  device. 

3. 1. 1.2. 2. 4  Mount /Unmount 


Mount  and  Unmount  shall  be  spawned  through  the  Secure  Server  mechanism. 
The  user  shall  supply  the  name  of  the  file  system  to  be  mounted,  the  drive  on 
which  the  file  system  resides,  the  pathname  of  a  presently  accessible  entry 
where  the  file  system  is  to  be  mounted  (normally,  the  tile  would  be  of  the 
directory  subtype),  and  an  optional  argument  indicating  that  the  file  system  is 
to  be  mounted  read  only. 

The  user  shall  have  discretionary  access  to  the  extent  (i.e.,  if  the  extent 
is  to  be  mounted  read/write,  the  user  must  have  read/write  access;  if  the  extent 
is  to  be  mounted  read  only,  the  user  must  have  read  access)  and  write  discre¬ 
tionary  access  to  the  entry  where  the  file  system  is  to  be  mounted  to  be  able  to 
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successfully  request  that  It  be  logically  mounted. 

The  Interface  to  the  Unmount  Process  shall  also  be  similar  to  that  In  the 
current  UNIX  system.  The  user  shall  supply  the  name  of  the  file  system  to  be 
unmounted . 

3. 1.1. 2. 2. 5  System  Startup /Shutdown 

The  user  Interface  to  the  System  Startup  Process  shall  consist  of  supplying 
the  name  and  location  (i*e.  extents)  of  the  Security  Kernel  and  Initial  Process 
Images  to  be  loaded.  This  Interface  is  provided  by  a  small  bootstrap  program 
which  is  loaded  using  the  ROM  bootstrap  or  other  mechanisms.  The  Initial  Pro¬ 
cess  shall  then  ask  the  user  for  the  location  of  the  root  file  system  and  for 
the  time. 


The  System  Shutdown  Process  shall  be  invoked  by  logging  in  as  a  special 
user  whose  default  "shell"  is  a  system  shutdown  program.  This  login  shall  be 
permitted  only  from  the  system  console,  and  shall  be  protected  by  the  usual 
password  protection  mechanisms. 

3. 1.1. 2. 2. 6  Secure  Mail 


The  user  interface  to  the  Secure  Mail  function  shall  consist  of  two  pro¬ 
grams  which  allow  for  the  sending  and  receiving  of  mall*  The  basic  interface 
shall  be  similar  to  the  interface  provided  by  the  current  UNIX  mail  program- 
However,  the  receive  mall  portion  shall  only  deliver  mall  that  exists  at  the 
security  level  of  the  Secure  Mail  process.  The  user  interface  shall  allow  the 
user  to  send  a  file  or  Input  from  his  terminal  to  one  or  more  other  users  iden¬ 
tified  by  their  login  Identifiers.  Mall  may  be  sent  by  users  running  at  any 
security  level  and  will  be  protected  at  that  level.  The  receive  part  of  the 
Secure  Mail  function  shall  allow  a  user  to  read  all  mall  sent  to  him  that  Is  at 
his  current  security  level.  To  read  mall  at  another  security  level,  the  user 
shall  be  required  to  change  his  security  level. 

3. 1.1. 2. 3  System  Maintenance  Services 

The  System  Maintenance  functions  shall  be  spawned  through  the  Secure  Server 
mechanism.  Input  parameters  and  output  are  defined  In  the  Detailed  Functional 
Requirements  below. 

3.1. 1.2.4  System  Administrative  Services 

The  System  Administrative  Services  class  of  Non-Kernel  Security  Related 
Software  shall  consist  of  the  functions  to  support  the  administrative  operation 
of  the  system,  such  as  adding  and  deleting  users. 

3-1. 1.2. 4.1  U3er  Control  Editor 

The  User  Control  Editor  shall  be  used  by  the  System  Administrator  to  con¬ 
trol  user  access  to  the  system.  Spe* ifically,  the  process  shall  be  used  by  the 
System  Administrator  to  add  and  delete  users  and  groups  from  the  system,  to 
change  user  and  group  access  level  capabilities,  to  change  a  user's  initial 
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login  group,  and  to  set  the  Identification  of  the  Group  Administrator  for  a 
group.  These  changes  shall  be  exercised  by  updating  the  User  Access  Authentica¬ 
tion  Data  Base  and  the  Group  Access  Authentication  Data  Base.  Since  all  deci¬ 
sions  about  access  In  KSOS  are  made  on  the  basis  of  information  contained  in 
these  data  bases,  the  interface  to  this  function  shall  be  via  the  secure  termi¬ 
nal  path;  i.e-,  the  function  shall  be  spawned  off  by  the  Secure  Server.  Altera¬ 
tion  of  these  data  bases  shall  not  affect  currently  logged  in  users  until  they 
request  some  service  for  which  one  of  the  data  bases  would  be  checked.  It  is 
recommended  that  the  System  Administrator  request  (or  force)  a  logout  of 
presently  active  users  affected  by  changes  to  these  data  bases. 

3 . 1 .  1 . 2 . 4 . 2  Immigration  Officer  Process 

The  function  of  the  Immigration  Officer  shall  be  to  check  the  acceptability 
of  "roreign"  tile  systems.  The  immigration  officer  process  shall  take  Lhe  name 
of  the  file  system  to  be  immigrated.  It  will  restore  (see  File  System  Restore 
CPC  3.2.2)  the  file  system  from  tape  and  checks  its  acceptability.  Only  after 
the  Immigration  Officer  has  approved  the  file  system  shall  it  be  acceptable  for 
mounting. 


3. I. 1.2.4. 3  Audit  Capture  Process 

The  Audit  Capture  Process  shall  receive,  via  either  the  signal  or  the 
inter-process  communication  mechanisms,  raw  audit  information  from  the  Kernel 
and  NKSR  processes.  It  shall  write  this  information  to  an  audit  file.  The  pro¬ 
cess  shall  be  able  to  select  the  types  of  information  to  be  kept  and  may  add 
additional  information  such  as  a  time  stamp  to  the  information  before  writing. 
Multiple  audit  files  shall  be  used  to  save  the  audit  information.  The  process 
shall  accept  a  command  from  the  System  Operator  to  switch  audit  files. 


3. 1.1. 2.4. 4  Privilege  Control  Process 


The  Privilege  Control  Process  shall  provide  the  Security  Officer  with  the 
ability  to  grant  and  revoke  special  access  privileges  for  process  image  files. 
Privileges  shall  be  given  to  processes  by  changing  elements  of  the  type  indepen¬ 
dent  information  for  the  file  from  which  the  process  is  invoked.  The  privileges 
of  presently  active  processes  shall  not  be  changed  by  the  Privilege  Control  Pro- 
The  following  privileges  shall  be  capable  of  being  granted  or  revoked: 

The  ability  to  violate  the  simple  security  property.  (This  privilege  is 
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g.  The  ability  to  use  the  K_release_openers  primtive- 

h.  The  ability  to  use  the  K_link  and  K_unllnk  primitives. 

1.  The  ability  to  use  the  K_mount  and  K_unmount  '  iltlves. 

j.  The  ability  to  change  the  following  type  independent  information  about  an 

object : 

1.  The  security  level  of  the  object. 

2.  The  integrity  level  of  the  object. 

3.  The  owner  of  the  object. 

k.  The  ability  to  set  type  dependent  information  (status)  about  an  object; 

l.e.,  the  ability  to  open  an  object  in  status  update  mode. 

l.  The  ability  to  save  the  process  image  in  the  swapping  area;  i.e.,  the  abil¬ 
ity  to  set  Lhe  "sticky  bit"  (ISVTXT). 

m.  The  ability  to  lock  a  segment  in  core  (not  swappable). 

n.  The  ability  to  grant  and  revoke  privileges. 

3. 2  Detailed  Functional  Requirements 

3.2.1  Secure  User  Services 

A  set  of  functions  shall  be  provided  which  communicate  with  the  user  termi¬ 
nal  through  a  secure  communications  path.  These  functions  shall  be  known  as 
Secure  User  Services. 

3. 2. 1.1  Secure  Initiator 


3 . 2 . 1 . 1 . 1  Users  and  Privileges 

The  Secure  Initiator  shall  be  invoked  by  the  Kernel  as  part  of  the  System 
by  the  Initial  Process  as  part  of  system  initialization. 

3.2. 1.1.2  Inputs 

The  Secure  Initiator  will  receive,  from  the  Initial  Process,  the  seids  for 
the  user  and  NKSR  process  bootstrapper  segments. 

3.2. 1.1.3  Processing 

The  Secure  Initiator  shall  spawn  off  the  Audit  Capture  Process  and  shall 
make  UNIX  directory  entries  for  the  Process  Bootstrapper  segments.  It  shall 
then  initialize  the  mount  table  and  the  access  levels  of  various  subtypes  and 
devices.  At  this  point,  the  Secure  Initiator  shall  execute  a  shell  file  of  com¬ 
mands  similar  to  the  rc  files  on  UNIX.  Finally,  the  Secure  Initiator  shall  set 
the  level  of  each  configured  terminal  and  spawn  off  a  Secure  Server  for  each 
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such  terminal. 

The  Secure  Initiator  shall  also  set  up  the  terminal  data  base  which  shall 
contain  a  list  of  terminals  coupled  with  the  Secure  Server  running  on  that  ter¬ 
minal.  This  data  base  shall  then  be  used  by  the  Secure  Servers. 

3.2. 1.1.4  Outputs 

The  Secure  Initiator  shall  pass  to  each  Secure  Server  the  identification  of 
the  teruinal  on  which  it  runs. 

3.2. 1.2  Secure  Server 

3 . 2 .  1 . 2 .  1  Users  and  Privileges 

A  separate  Secure  Server  shall  be  a  spawned  to  service  each  terminal- 

This  Server  shall  be  privileged  to  use  the  K_secure_terminal_lock  Kernel 
call,  to  change  certain  type  independent  information  about  an  object,  and  to 
change  process  type  independent  information- 

3.2. 1.2.2  Inputs 

The  process  shall  receive  input  from  the  Secure  Initiator  in  the  form  of  an 
argument  Segment,  and  from  the  user  terminal  via  the  secure  terminal  path. 

Inputs  from  the  user  shall  consist  of  the  name  of  the  service  to  be  per¬ 
formed  and  an  arguments  which  may  be  needed  by  that  service. 

3. 2. 1.2. 3  Processing 

The  Secure  Server  shall  prompt  the  user  and  read  from  the  secure  terminal 
path  to  determine  type  of  service  required.  If  the  Server  Is  unable  to  deter¬ 
mine  the  type  of  service  required,  it  shall  display  a  rejection  request  on  the 
user's  terminal  and  thaw  the  terminal.  In  the  case  of  operator  requests,  the 
Server  shall  determine  that  the  user  Is  currently  running  at  OPERATOR  integrity 
level  or  higher  before  an  the  function  Is  performed.  In  the  case  of  administra¬ 
tor  requests,  the  Server  shall  determine  that  the  user  Is  currently  running  at 
ADMINISTRATOR  Integrity  level  before  an  the  function  Is  performed. 

The  Secure  Server  shall  process  user  requests  using  a  combination  of 
spawned  processes  as  needed  to  service  user  requests.  Processing  required  for 
each  type  of  service  Is  described  In  the  processing  section  for  that  service. 

3.2. 1.2.4  Outputs 

The  Secure  Server  shall  communicate  to  the  terminal  user  via  the  secure 
terminal  path.  Upon  receiving  an  IPC  signal  from  the  Initiator  the  Secure 
Server  shall  display  the  user's  current  security  level  as  a  character  string 
sent  out  on  the  secure  path.  Process  which  are  spawned  by  the  Secure  Server 
shall  receive  their  arguments  via  an  argument  segment. 
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Outputs  required  for  each  type  of  service  are  listed  In  the  outputs  section 
for  that  service. 

3.2. 1.3  Access  Authentication  Functions 


The  Access  Authentication  Functions  shall  process  requests  for  login, 
change  group,  setting  terminal  access  level,  and  logout.  These  functions  shall 
be  internal  to  the  Secure  Server  process. 

3. 2. 1 . 3. 1  Inputs 

Valid  user  names  and  Identifiers,  encrypted  passwords,  and  the  user  access 
matrix  shall  be  available  from  the  User  Access  Authentication  Data  Base. 

Valid  group  names  and  identifiers,  encrypted  passwords,  and  the  group 
access  matrix  shall  be  available  from  the  Group  Access  Authentication  Data  Base. 

Profile  information  for  each  terminal  shall  be  available  from  the  Terminal 
Profile  Data  Base.  The  user's  name,  unencrypted  password,  and  group  name  shall 
be  obtained  via  the  secure  terminal  path. 

3. 2. 1.3. 2  Processing 

The  Access  Authentication  Functions  shall  process  user  requests  for  logging 
In,  logging  out,  changing  group  .and  changing  access  level.  Additionally,  they 
shall  process  certain  requests  from  the  System  Operator  which  control 
login/ logout . 

3. 2. I. 3. 2.1  Login  Processing 

After  receiving  a  login  request  the  current  state  of  the  terminal  shall  be 
checked.  If  the  terminal  is  currently  logged-ln,  the  request  shall  be  denied. 
If  the  terminal  is  not  logged-in  a  message  shall  be  displayed  on  the  terminal 
requesting  the  user's  login  name.  After  obtaining  the  user's  login  name,  the 
process  shall  disable  echoing  on  the  terminal  and  request  the  user's  password. 
The  password  entered  by  the  user  shall  then  be  encrypted  and  the  user's  login 
name  and  encrypted  password  shall  be  checked  against  the  User  Access  Authentica¬ 
tion  Data  Base.  If  there  is  no  match,  the  login  name  and  password  will  be 
requested  again.  Only  a  small  number  of  retries  shall  be  allowed.  If  this 
retry  limit  is  exceeded  the  development  contractor  shall  provide  a  mechanism  for 
the  notification  of  the  System  Security  Officer.  If  there  Is  a  match,  the  pro¬ 
cessing  shall  continue.  If  the  User  Access  Authentication  Data  Base  Indicates  a 
login  group,  the  group  shall  be  checked  against  the  Group  Access  Authentication 
Data  Base  and  If  valid,  shall  be  used  as  the  user's  group  without  requiring  a 
group  password.  If  no  group  Is  indicated,  the  system  default  group  shall  be 
used.  All  users  shall  be  Initially  logged  In  at  their  default  security  and 
integrity  level  unless  that  level  is  above  the  current  maximum  permitted  on  the 
system,  in  which  case  the  user's  level  shall  be  set  to  the  system  low,  and  he 
shall  be  informed  of  his  level  (system  low).  The  following  functions  shall  be 
performed  in  logging  in  a  user: 

a.  Select  a  terminal  path,  change  the  security  and  Integrity  levels  for  that 

path  to  the  login  level  of  the  user,  and  the  ovn,  of  the  path  to  the  user. 
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b.  K_spawn  a  process  at  the  user's  login  level  which  will  cause  the  user's 
shell  to  start  running  on  the  UNIX  Emulator  with  the  selected  user  path  as 
the  standard  input  and  output.  The  use  of  the  K_spawn  primitive  shall 
remove  any  special  privileges  possessed  by  the  Secure  Server. 

3 • 2 . 1 • 3 . 2 . 2  Changing  Croup 

After  receiving  a  request  to  change  group,  a  message  shall  be  displayed  on 
the  user's  terminal  requesting  the  name  of  the  group  desired.  The  group  name 
shall  be  checked  against  the  Group  Access  Authentication  Data  Base  to  determine 
if  the  group  Is  valid  and  If  the  user's  present  access  level  is  permissible  for 
the  requested  group.  If  a  password  ror  the  group  is  listed  the  user  shall  be 
asked  the  password  which  shali  be  encrypted  and  checked.  If  successful,  the 
requested  group  ID  shall  be  Set  for  the  user,  otherwise  a  rejection  message 
shall  be  displayed  on  the  user's  terminal.  As  in  login  processing,  only  a  lim¬ 
ited  number  of  attempts  shall  be  permitted  before  notification  of  the  System 
Security  Officer. 

3. 2. 1.3. 2. 3  Change  Access  Level 

Upon  requests  by  the  user  to  change  his  current  access  level,  the  Server 
shall  check  that  the  requested  level  is  valid  for  the  user,  group,  and  terminal 
by  checking  the  appropriate  data  bases.  The  Server  shall  also  verify  that  the 
requested  level  is  permitted  on  the  system  at  that  time  (i.e.  that  the  requested 
level  is  at  or  below  the  current  system  high  level).  The  Server  shall  then 
determine  whether  or  not  the  user  has  an  active  environment  (usually  a  shell 
running  on  a  UNIX  Emulator)  at  this  level.  If  so,  the  Server  shall  select  the 
user  path  with  the  previous  environment.  If  the  user  does  not  have  an  active 
environment  at  this  level,  the  Server  shall  attempt  to  find  an  inactive  user 
path  for  that  terminal  and  if  successful,  set  the  path  level  to  the  desired 
level  and  spawn  a  shell  and  emulator  at  that  level. 

3.2. 1. 3. 2. 4  Logout 


Requests  for  logout  shall  cause  a  signal  to  be  sent  to  all  user  processes 
invoked  tor  that  terminal  requesting  them  to  terminate.  User  processes  which  do 
not  terminate  within  a  reasonable  time  will  be  killed.  The  terminal  mode 
(speed,  parity,  etc)  shall  be  set  to  the  values  listed  for  it  in  the  Terminal 
Profile  Data  Base. 

3. 2. 1.3. 2. 5  Processing  Operator  Requests 

The  Access  Authentication  Functions  shall  accept  and  enforce  commands  from 
the  System  Operator  to  control  user  login,  access  levels,  and  logout. 

3. 2. 1.3. 3  Outputs 

An  accounting  message  shall  be  sent  to  the  Audit  Capture  Process  for  each 
request  even  if  the  request  was  denied. 
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3.2- 1.4  Password  Modification  Function 


3.2. 1.4.1  Inputs 

The  Password  Modification  Function  shall  have  read/write  access  to  the  User 
Access  Authentication  Data  Base  and  the  Group  Access  Authentication  Data  Base. 
The  Password  Modification  Function  shall  communicate  with  the  user  via  the 
secure  terminal  path. 

3. 2. 1.4. 2  Processing 

After  receiving  a  request  for  password  modification,  the  Secure  Server 
shall  invoke  the  Password  Modification  Function  to  handle  the  request.  The 
Password  Modifier  shall  turn  off  echoing  on  the  user's  terminal  and  request  the 
user's  old  password  which  is  then  encrypted  and  checked  againist  the  User  Access 
Authentication  Database.  This  check  is  done  to  insure  that  the  person  on  the 
terminal  is  the  real  user  for  the  logged  in  user  ID.  The  user  will  then  be 
requested  to  enter  the  desired  new  password.  The  user  shall  be  requested  to 
enter  the  new  password  a  second  time.  If  the  two  entries  do  not  match  the  user 
shall  be  informed  and  the  process  repeated.  The  new  password  shall  be  encrypted 
and  written  into  the  User  Access  Authentication  Data  Base.  The  user  shall  be 
allowed  to  modify  a  group  password  in  a  similar  manner  if  he  has  been  designated 
in  the  Group  Access  Authentication  Database  as  the  Group  Administrator  for  that 
group. 

3.2. 1.4.3  Outputs 

The  Password  Modification  Function  shall  write  to  the  user  terminal  via  the 
secure  terminal  path. 

The  Password  Modification  Function  shall  write  new  passwords  in  the  User 
Access  Authentication  Data  Base,  and  the  Group  Access  Authentication  Database  as 
required . 

Audit  information  noting  that  the  password  has  been  changed  will  be  cap¬ 
tured. 


3. 2.1. 5  File  Access  Modification  Function 

User  requests  to  change  the  access  level  and  owner  of  a  file  shall  be  pro¬ 
cessed  by  the  File  Access  Modification  Function. 

3. 2. 1 . 5. 1  Inputs 

The  File  Access  Modification  Function  shall  receive  input  from  the  user  via 
the  secure  terminal  oath  including  the  pathname  of  the  file  to  be  modified. 

The  File  Access  Modifier  shall  have  access  to  status  information  on  all 
files. 
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3. 2. 1. 5. 2  Processing 


The  File  Access  Modifier  shall  request  from  the  user  the  path  name  of  the 
file  to  be  modified.  It  then  checks  for  the  existence  and  ownership  of  the 
file.  If  the  requester  can  not  access  the  file,  or  the  requester  is  not  the 
owner,  or  the  requester,  if  not  the  owner,  is  not  at  ADMINISTRATOR  level,  or  the 
file  is  open,  the  request  shall  be  denied.  If  these  checks  all  succeed,  the 
user  shall  then  be  asked  the  operation  to  be  performed. 

For  a  request  to  change  access  level,  checks  shall  be  made  to  determine 
that  the  file  exists,  that  the  requested  level  is  allowed  on  the  file  system  on 
which  the  file  resides  and  that  the  requester's  access  matrix  includes  the 
requested  level.  Ir  these  checks  are  successful  the  level  of  the  file  shall  be 
changed . 

For  changing  the  owner  of  a  file,  the  Server  shall  check  that  the  user  is 
the  owner  of  the  file  or  is  at  the  ADMINISTRATOR  or  higher  integrity  level,  that 
the  file  exists,  that  the  file  is  not  open,  and  that  the  new  owner  exists.  If 
these  checks  are  successful,  the  owner  of  the  file  shall  be  changed. 

3. 2. I. 5.3  Outputs 

The  File  Access  Modifier  shall  display  the  current  level,  discretionary 
access  information,  and  owner  prior  to  changing  any  of  this  information.  In 
addition,  the  proposed  new  values  shall  be  displayed  prior  to  actually  changing 
them.  In  the  case  of  a  change  owner  a  message  shall  be  sent  to  the  new  owner 
informing  him  that  he  has  become  the  file  owner.  All  output  to  the  user  termi¬ 
nal  shall  be  via  the  secure  terminal  path. 

Audit  information  shall  be  gathered  on  each  request  even  if  the  request  was 
denied. 

3.2.2  System  Operation  Services 
3.2.2. I  Network  Daemon 

The  computer  network  interface  functions  are  spread  across  the  UNIX  Emula¬ 
tor,  the  Security  Kernel  and  the  Network  Daemon.  Table  1  shows  the  overall  func¬ 
tional  division.  The  remainder  of  this  paragraph  discusses  the  functions  per¬ 
formed  by  the  Network  Daemon. 
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Table  I 

TCP  Functional  Allocation 


Security 

Kernel 

UNIX  Network 

Emu 1 a t  or  Daemon 

IMP  Support 

X 

Rendezvous 

X 

Flow  Control 

X 

Data  Stream 
Integrity: 

Checksum 

Resequence 
Retransmission 
Acknowledge 
Duplicate  Detect 

X 

X 

X 

X 

X 

Routing 

X 

Connection  Alloc. 

X 

Urgent  Processing 

X 

Formatting 

X 

Security  Level 
of  Message 

X 

3. 2.2. 1.1  Users  and  Privileges 

The  Network  Daemon  shall  be  a  general  service  program  utilized  by  all  users 
of  the  network.  The  Network  Daemon  shall  be  privileged  to  violate  the  security 
♦-property  to  allow  It  to  service  a  multi-level  network.  If  the  network  is  at 
only  one  security  level,  the  Network  Daemon  is  unprivileged. 

3. 2. 2. 1.2  Inputs 

The  inputs  to  the  Network  Daemon  are  the  data  streams  to  and  from  the  net¬ 
work,  and  the  control  requests  from  the  System  Operator. 

3.2.2. 1.3  Processing 

This  paragraph  discusses  the  functions  of  Table  I  which  are  performed  by 
the  Network  Daemon. 
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3. 2. 2. 1.3.1  Rendezvous 


Rendezvous  is  the  process  of  recognizing  the  match  of  connection  names. 
For  example,  a  remote  user  supplies,  as  part  of  his  connection  attempt,  a  local 
TCP  port  name  to  which  he  wishes  to  be  connected.  The  process  of  matching  the 
local  name  (on  which  some  local  process  is  listening)  to  the  name  being  supplied 
by  the  remote  process  is  called  rendezvous.  To  accomplish  the  rendezvous,  the 
Network  Daemon  shall  maintain  a  table  of  connections  and  their  names,  both  local 
and  remote. 

The  Network  Daemon  shall  provide  the  management  of  the  internal  tables 
necessary  to  provide  the  overall  network  services.  These  tables  shall  include, 
but  are  not  limited  to,  the  host  status  tables,  the  table  containing  the  connec¬ 
tion  status  for  each  open  connection,  and  tables  containing  internal  status 
information. 

3.2.2. 1-3.2  Checksum 

To  allow  for  proper  internal  routing,  the  Network  Daemon  shall  compute  the 
checksum  of  incoming  messages.  Messages  received  with  an  incorrect  checksum 
shall  be  discarded  in  keeping  with  the  TCP  definition  [Postel  78a]  [Postel  78b]. 
The  Network  Daemon  shall  also  compute  the  checksum  for  all  outbound  messages. 
The  formula  to  be  used  for  checksum  calculation  will  be  supplied  by  the  Covern- 
ment . 


3. 2. 2. 1.3. 3  Routing 

The  Network  Daemon  shall  supply  the  routing  information  required  by  the 
network  by  mapping  the  user  specified  destination  into  the  appropriate  coded 
form. 


3. 2. 2. 1.3. 4  Connection  Allocation 


The  Network  Daemon  shall  control  the  allocation  of  the  connection  resource. 
This  allocation  shall  include  the  maintenance  of  internal  tables  describing  the 
state  of  each  connection.  For  active  connections,  this  state  also  includes  the 
information  necessary  to  route  inbound  packets  to  the  appropriate  process  and  to 
fill  in  the  fields  for  the  destination  on  outbound  traffic.  The  System  Operator 
may  manipulate  the  state  of  connections  via  the  System  Operator  interface.  This 
latter  mode  of  operation  is  expected  to  be  used  infrequently. 

3.2. 2. 1.3. 5  Message  Security  Level 

The  Network  Daemon  shall  supply  the  security  level  field  of  outbound  mes¬ 
sages  based  on  the  Kernel-supplied  value  for  the  level  of  the  sending  process  if 
this  field  is  supported  by  the  network.  If  the  network  does  not  support  messages 
of  differing  classification  (e.g.,  a  single  level  network)  the  Network  Daemon 
shall  not  transmit  messages  whose  security  level  is  above  the  level  of  the  net¬ 
work.  The  Network  Daemon  shall  examine  the  security  level  of  incoming  messages 
to  assure  that  they  can  be  delivered  to  the  receiving  process  without  violation 
of  the  mandatory  security  policy.  The  security  level  of  a  message  may  be  impli¬ 
cit,  as  in  the  case  of  single  level  networks. 
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In  the  case  of  single  level  networks,  the  Security  Kernel  shall  provide 
many  of  the  message  security  level  functions  by  permitting  (and  denying)  Inter¬ 
process  communication  attempts  to  the  Network  Daemon*  In  these  cases,  the  Net¬ 
work  Daemon  may  be  a  process  running  at  the  level  of  the  network.  Attempts  by 
processes  of  higher  security  level  to  communicate  with  the  Network  Daemon  would 
be  denied  by  the  Security  Kernel* 

3*2. 2. 1.4  Outputs 

The  outputs  of  the  Network  Daemon  are  the  data  streams  to  and  from  the  net¬ 
work  and  any  diagnostic  messages. 

3 . 2 . 2 . 2  Line  Printer  Spooling 

3 . 2 . 2 . 2 . 1  Users  and  Privileges 

The  Line  Printer  Spooler  shall  be  an  unprivileged  service  function  avail¬ 
able  to  all  system  users* 

The  Line  Printer  Daemon  (de-spooler)  shall  be  responsible  for  the  printing 
of  the  appropriate  classification  markings  on  its  output  and  shall  be  privileged 
to  violate  the  security  *-properlty  to  remove  printed  spool  files. 

3. 2. 2. 2. 2  Inputs 

The  Inputs  to  the  Line  Printer  Spooler  shall  be  the  flies  to  be  printed 
(which  defaults  to  the  standard  Input  If  not  supplied)  and  the  control  Informa¬ 
tion  discussed  In  section  3. I. 1.2. 2. 2.  The  Inputs  to  the  Line  Printer  Daemon 
shall  be  the  previously  spooled  output  flies  and  control  commands  from  the  Sys¬ 
tem  Operator. 

3. 2. 2. 2. 3  Processlne 

The  overall  flow  of  processing  in  the  Line  Printer  Spooler  shall  be  as 
shown  In  Figure  3-2. 
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The  spooler  shall  make  a  copy  of  the  files  to  be  spooled,  which,  together  with 
any  control  information,  shall  be  placed  in  the  spool  directory.  This  direc¬ 
tory,  as  well  as  the  files  it  contains,  shall  have  a  discretionary  access  pro¬ 
tection  which  disallows  access  to  all  users  other  than  "spool",  the  spooler 
manager . 

Using  the  corresponding  control  information,  the  Line  Printer  Daemon  shall 
print  each  spooled  file.  The  Daemon  shall  apply  the  appropriate  headers, 
footers,  and  burst  page  information  to  correctly  mark  the  classification  of  the 
ouLput.  Markings  shall  be  in  accordance  with  DoD  Directive  5200. 1-R.  The  Daemon 
shall  create  auditing  records  noting  the  creation  of  classified  output.  Finally, 
the  Daemon  shall  delete  the  spooled  output  file  after  the  printing  has  been  suc¬ 
cessfully  completed. 

The  Daemon  shall  respond  to  inter-process  communication  from  the  System 
Operator,  as  defined  by  the  Daemon  Control  Interface  above.  The  Daemon  shall  be 
capable  of  aborting  the  printing  of  a  file  and  of  backing  up  a  page  for  paper 
changes . 


3. 2. 2. 2. 4  Outputs 

The  output  of  the  Spooler  shall  be  the  temporary  files  to  be  subsequently 
printed  by  the  Daemon.  The  output  of  the  Daemon  shall  be  the  printed  output  and 
the  auditing  records  indicating  the  creation  of  classified  output. 

3. 2. 2. 3  Assign /Deassign 

3. 2. 2. 3.1  Users  and  Privileges 

The  use  of  assign  shall  be  unrestricted  although  the  ability  to  assign  cer¬ 
tain  devices  may  be  restricted.  The  Assign  and  Deassign  functions  shall  be 
privileged  to  change  the  owner  and  level  of  a  device;  i.e.,  to  set  the  type 
independent  intormation  for  the  device. 

3. 2. 2. 3. 2  Inputs 


The  user  input  to  Assign  shall  specify  the  device(s)  to  be  assigned.  The 
input  to  Deassign  shall  indicate  the  device(s)  to  be  deassigned.  Both  processes 
shall  have  access  to  the  type  independent  status  of  devices. 

3. 2.2. 3. 3  Processing 

Upon  receipt  of  a  request  to  assign  a  device,  the  Assign  process  shall 
check  the  current  owner  of  the  device.  If  the  device  is  not  owned  by  the  System 
Resource  Manager,  the  process  will  assume  the  device  is  presently  assigned  and 
disallow  the  request  since  a  device  can  only  be  assigned  to  one  user  at  a  time. 
If  the  level  of  the  user  requesting  the  device  is  higher  that  the  maximum  level 
allowed  for  that  device,  the  request  will  also  be  denied.  To  assign  a  device. 
Assign  shall  change  the  owner  and  access  level  of  the  device  to  that  of  the 
requester  and  the  discretionary  access  permissions  to  read/write  by  owner. 

Deassignment  of  a  device  must  be  requested  either  by  the  current  device 
owner  or  the  System  Operator.  The  device  ownership  shall  be  return  to  the  System 
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Resource  Manager  upon  deass ignment . 

3. 2. 2. 3. 4  Outputs 

The  Assign  and  Deassign  processes  shall  output  messages  as  necessary  to  the 

user  • 

3. 2. 2. 4  Mount /Unmount 


3 . 2 . 2 . 4 . 1  Users  and  Privileges 

The  use  of  the  Mount  and  Unmount  Processes  shall  be  unrestricted,  however, 
the  ability  to  mount  and  unmount  particular  file  systems  or  to  mount  on  particu¬ 
lar  devices  may  be  restricted. 

The  Mount  Process  shall  have  the  permissions  needed  to  access  the  underly¬ 
ing  devices. 

3. 2. 2. 4. 2  Inputs 


The  user  inputs  to  Mount  shall  be  the  name  of  the  file  system  to  be 
mounted,  the  drive  on  which  the  file  system  resides,  the  pathname  of  a  presently 
accessible  file  (normally,  the  file  would  be  of  directory  subtype),  and  an 
optional  argument  indicating  that  the  file  system  is  to  be  mounted  read  only. 
If  no  arguments  are  given,  a  list  of  the  currently  mounted  file  systems  is 
given. 

The  process  shall  also  read  a  file,  maintained  by  the  Immigration  Officer 
Process,  containing  the  file  systems  which  are  acceptable  for  mounting. 

The  Unmount  Process  inputs  from  the  user  shall  be  the  drive  to  be 
unmounted • 

3. 2. 2. 4. 3  Processing 

The  Mount  Process  shall  verify  that  the  file  system  is  acceptable  for 
mounting  by  checking  that  the  file  system  is  on  the  list  maintained  by  the  Immi¬ 
gration  Officer  Process  and  that  it  is  not  already  mounted.  Mount  shall  also 
check  that  the  user  has  discretionary  access  to  the  file  system  (l*e.,  if  the 
file  system  is  to  be  mounted  read/write,  the  user  must  have  read/write  access; 
if  the  file  system  is  to  be  mounted  read  only,  the  user  must  have  read  access), 
that  the  user  has  write  access  to  the  parent  directory,  that  the  user's  security 
and  integrity  levels  are  greater  than  or  equal  to  the  file  system's  level,  and 
that  the  file  system's  set  of  security  compartments  is  a  subset  of  the  user's 
set.  If  any  of  these  checks  fail,  the  process  shall  send  a  message  to  the  Audit 
Capture  Process  and  notify  the  user  of  the  failure.  If  the  checks  are  success¬ 
ful,  the  Mount  Process  shall  issue  the  K_mount  Kernel  call  which  will  logically 
mount  the  file  system.  The  UNIX  directory  manager  (UDM)  ZZZ  will  then  be  called 
to  add  the  file  system  Into  the  UNIX  structure. 

The  Unmount  Process  shall  check  that  the  user  has  permission  to  unmount  the 
file  system;  i.e.,  the  user  has  discretionary  access  to  the  file  system,  has 
write  access  to  the  mount  on  entry  of  the  directory  being  unmounted,  and  has  the 
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appropriate  security  level,  integrity  level,  and  security  compartments  as 
described  in  the  section  on  Mount.  If  these  checks  are  successful,  the  Unmount 
Process  shall  issue  the  K_unmount  Kernel  call.  Followed  by  a  call  to  the  UNIX 
directory  manager  to  remove  the  file  system  from  the  UNIX  structure. 

3. 2. 2. 4. 4  Outputs 

The  Mount  and  Unmount  Processes  shall  update  a  file  analogous  to  the  file 
/etc/mount  in  current  UNIX  which  is  used  to  inform  users  which  file  systems  are 
presently  mounted.  Both  processes  shall  provide  diagnostic  messages  as  required. 

3.2.2. 5  System  Startup /Shutdown 

3 . 2 . 2 . 5 . 1  Users  and  Privileges 

The  use  ot  the  System  Startup  and  Shutdown  mechanisms  sha.,1  be  restricted 
to  the  System  Operator.  Since  the  KSOS  system  is  not  in  operation  when  the  Sys¬ 
tem  Startup  mechanism  is  invoked,  and,  thus,  cannot  protect  itself,  the  System 
Startup  mechanism  shall  be  further  restricted  to  be  used  only  from  the 
operator's  console.  The  System  Shutdown  mechanism  shall  be  similarly  restricted 
because  the  KSOS  system  will  be  unavailable  to  protect  itself  after  the  shutdown 
is  complete. 

3. 2. 2. 5. 2  Inputs 

The  inputs  to  the  System  Startup  Process  shall  be  the  name  of  the  KSOS 
image  and  of  the  Initial  Process  image  to  be  loaded.  Locally  specified  func¬ 
tions  may  require  additional  inputs.  The  Initial  Process  shall  then  ask  the 
user  for  the  time,  the  location  of  the  root  file  system,  and  the  Secure  Initia¬ 
tor  to  be  used. 

No  inputs  to  the  System  Shutdown  Process  are  required.  Locally  specified 
functions  may  require  additional  inputs. 

3. 2. 2. 5. 3  Processing 

The  System  Startup  Process  shall  begin  by  having  the  ROM  bootloader  (or 
equivalent)  load  a  KSOS  bootstrap.  This  bootstrap  shall  then  load  the  Kernel  and 
Initial  Process,  and  initialize  the  system  hardware  to  allow  proper  execution  of 
the  Kernel.  The  Kernel  will  perform  any  internal  Initialization  required.  It 
will  then  set  up  internal  tables,  etc.  to  allow  the  Initial  Process  image  to  run 
as  a  user  process,  and  will  begin  running  it. 

The  Initial  Process  shall  set  the  time  of  day  clock,  mount  the  root  file 
system,  and  build  the  segments  used  by  the  Process  Bootstrapper  (PBB).  The  pro¬ 
cess  shall  then  issue  a  K_invoke  call  to  invoke  the  Secure  Initiator. 

The  System  Shutdown  Process  shall  first  execute  a  locally  modifiable  shell 
file  to  accomplish  any  desired  local  processing.  It  shall  then  "kill"  all  user 
processes,  force  all  cached  I/O  to  be  completed,  and  call  K_halt  to  halt  the 
kernel . 
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3 .  2 .  2 .  5 . 4  Out  put  3. 

The  System  Startup  and  Shutdown  Processes  shall  have  no  outputs  other  than 
diagnostic  and  informational  messages.  Sites  may  elect  to  include  additional 
output  from  their  locally  specified  startup  and  shutdown  shell  files. 

3. 2. 2. 6  Secure  Mail 

3. 2- 2. 6.1  Users  and  Privileges 

The  Secure  Mail  mechanism  shall  be  a  service  available  to  all  users.  .  It 
shall  be  unprivileged. 

3 • 2 . 2 . 6 . 2  Inputs 

The  input  for  the  send  part  of  Secure  Mail  shall  be  the  name  of  a  file  to 

be  mailed  (which  shall  default  to  the  standard  input  if  not  supplied),  and  the 

list  of  users  to  whom  the  mail  is  to  be  sent. 

The  input  for  the  receive  part  of  Secure  Mail  shall  be  the  previously 

transmitted  letters,  if  any,  and  an  (optional)  file  name  in  which  to  save  the 

mail . 

3. 2. 2. 6. 3  Processing 

Conceptually,  Secure  Mail  shall  be  similar  to  "two  ended  spooling".  The 
sending  process  shall  place  the  mail  in  a  "post  office  box"  directory  that  is 
unique  for  each  user.  This  directory  as  well  as  the  files  (letters)  placed  in 
it,  shall  be  owned  by  the  user  "post"  and  shall  have  discretionary  access  pro¬ 
tections  that  disallow  access  to  all  users  other  than  "post". 

The  receive  mail  process  shall  retrieve  the  letters  from  the  user's  "post 
office  directory"  and  place  them  in  a  user  specified  directory.  So  that  secu¬ 
rity  upgrading  of  letters  does  not  occur,  the  user  shall  only  be  allowed  to 
receive  letters  as  his  current  security  level.  The  mail  may  then  be  examined  by 
the  user. 

3. 2. 2. 6. 4  Outputs 

The  output  of  the  send  part  of  Secure  Mail  shall  be  the  letters  created 
under  the  /post /to_user  directories,  and  any  diagnostic  information  required, 
such  as  that  the  specified  recipient  does  not  exist.  The  output  of  the  receive 
part  shall  be  a  file  in  the  user's  mail  directory. 

3.2.3  System  Maintenance  Services 

This  class  of  Non-Kernel  Security  elated  Software  shall  consist  of  those 
functions  that  provide  facility  for: 

a.  file  system  backup  and  restoration 

b.  file  system  consistency  check  and  repair 
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c.  system  distribution,  generation,  and  reconfiguration 

3 • 2 • 3 . 1  File-system  Backup  and  Restoration 

The  Dump  and  Restore  functions  shall  provide  a  mechanism  for  the  generation 
and  recovery  of  incremental  and  complete  file  system  dumps  of  KSOS  files.  Both 
Dump  and  Restore  programs  shall  be  trusted  to  allow  the  reading  and  creation  of 
multi-level  file  objects. 

3.2.3. 1.1  Pump 


3.2.3. 1.1.1  Users  and  Privileges 

Use  of  the  Dump  program  shall  be  restricted  to  the  Operator  level  and 
above.  The  program  shall  have  the  permissions  needed  to  access  the  disk  devices 
directly  (rather  than  going  through  the  Security  Kernel  and  UNIX  Emulator  file 
systems) . 

3.2. 3. 1.1.2  Inputs 

The  inputs  to  the  Dump  program  shall  be  similar  to  the  inputs  to  the 
current  UNIX  dump  program: 

a.  parameters  which  describe  precisely  what  is  to  be  dumped 

b.  the  name  of  the  file  system(s)  to  be  dumped 

c.  the  data  from  the  file  system  being  dumped 

3.2.3. 1.1.3  Processing 

After  determining  that  the  invoking  user  has  a  sufficient  access  level  to 
run  the  Dump  program,  the  program  shall  copy  a  KSOS  file  system  to  its  output  in 
a  dump  format.  Dump  shall  he  capable  of  producing  an  incremental  dump  of  a 
specified  KSOS  file  system.  The  incremental  dump  shall  include  all  files  that 
have  changed  since  the  last  full  dump,  or  in  a  specified  period. 

3. 2. 3. 1.1.4  Outputs 

Output  of  the  Dump  program  shall  be  to  a  9-track  magnetic  tape  or  other 
removable  storage  medium.  The  Dump  program  shall  allow  its  output  to  be  directed 
to  a  disk  or  equivalent. 

3.2.3. 1.2  Restore 


3.2.3. 1.2.1  Users  and  Privileges 

Use  of  the  Restore  program  shall  be  restricted  to  the  Operator  level  and 
above.  The  program  shall  have  the  permissions  needed  to  access  the  disk  devices 
directly  (rather  than  going  through  the  UNIX  Emulator  file  systems). 
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3-2-3. L.2.2  Inputs 

The  Inputs  to  the  Restore  program  shall  be  similar  to  those  used  by  the 
current  restor(VII)  [Thompson  75]  program: 

a.  parameters  describing  precisely  what  is  to  be  restored 

b.  the  name  of  the  file  system  to  be  restored 

c.  the  data  previously  dumped  that  is  to  be  restored 

3.2.3. 1.2. 3  Processing 

After  validating  that  the  user  is  privileged  to  restore  a  file  system,  the 
Restore  program  shall  (selectively)  restore  to  the  designated  file  system- 

3.2. 3. 1.2.4  Outputs 

The  output  of  the  Restore  program  shall  consist  of  the  restored  files  or 
file  system,  and  any  diagnostic  messages  produced. 

3.2. 3-2  File  System  Maintenance  Services 


3. 2.3.2. 1  Make  File  System 

3 . 2 . 3 . 2 . 1 . 1  Users  and  Privileges 

• 

Operation  of  the  Make  File  System  program  shall  be  allowed  only  by  the  Sys¬ 
tem  Administrator  since  the  contents  of  the  target  pack,  extent,  or  file  system 
are  destroyed  by  the  initialization  process.  The  program  shall  have  the  permis¬ 
sions  needed  to  access  the  underlying  device  files,  rather  than  going  through 
the  Security  Kernel's  or  UNIX  Emulator's  file  systems. 

3. 2. 3. 2. 1.2  Inputs 

The  inputs  to  the  Make  File  System  program  shall  include  the  parameters 
which  describe  the  initial  state  of  the  pack,  extent,  or  file  system  which  is 
being  initialized. 

3. 2. 3. 2. 1.3  Processing 

The  Make  File  System  program  shall  initialize  the  pack,  extent,  or  file 
system  in  accordance  with  the  parameters  supplied.  The  program  may  implement 
safety  measures  to  reduce  the  probability  of  accidentally  re-initializing  a  file 
system. 


3 . 2 . 3 • 2 . 1 . 4  Outputs 

The  outputs  of  the  Make  File  System  program  shall  include  the  newly  ini¬ 
tialized  pack,  extent,  or  file  system,  and  any  diagnostic  or  warning  messages. 
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3. 2. 3. 2. 2  Directory  Consistency  Check 
3. 2. 3-2-2- 1  Users  and  Privileges 

The  use  of  the  Directory  Consistency  Check  program  shall  be  limited  to  the 
System  Operator  level  and  above  since  It  requires  access  to  the  underlying 
device(s)  on  which  the  file  system  Is  built* 

3.2. 3*2. 2. 2  Inputs 

The  input  to  the  Directory  Consistency  Check  program  shall  include  the  name 
of  the  file  system  to  be  checked. 

3. 2. 3. 2. 2. 3  Processing 

The  program  shall  read  the  UNIX  file  system  directories  on  the  device,  and 
compute  the  actual  and  expected  link  counts  for  each  file.  Counts  that  do  not 
match  shall  be  reported.  In  addition,  any  file  which  has  an  actual  and  an 
expected  count  of  zero  shall  be  reported. 

3. 2. 3. 2. 2. 4  Outputs 


The  outputs  of  the  Directory  Consistency  Check  program  shall  include  the 
diagnostic  messages  discussed  above.  The  program  shall  also  report  the  absence 
no  anomalies  in  the  structure  of  the  file  system. 

3. 2. 3. 2. 3  Storage  Consistency  Check 

3 . 2 . 3 . 2 . 3 • 1  Users  and  Privileges 

The  use  of  the  Storage  Consistency  Check  program  shall  be  limited  to  the 
System  Operator  level  and  above  since  it  requires  access  to  the  underlying 
device (s)  on  which  the  file  system  is  built. 

3. 2. 3-2. 3. 2  Inputs 


The  inputs  to  the  Storage  Consistency  Check  program  shall  include  the  dev¬ 
ice  to  be  checked  and  parameters  to  control  the  optional  processing. 

3 . 2 . 3 • 2 . 3 . 3  Processing 

The  program  shall  examine  the  named  file  system  to  determine  that  all 
allocated  areas  of  the  file  system  are  mutually  exclusive  and  that  all  storage 
areas  are  accounted  for  in  the  file  system.  The  program  shall  have  the  capabil¬ 
ity  to  identify  files  that  Include  named  blocks. 

3. 2. 3. 2. 3. 4  Outputs 

The  output  of  the  Storage  Consistency  Check  program  shall  include  a  summary 
of  the  storage  allocation  on  the  device  Including  any  diagnostic  information 
about  missing  or  multiply  allocated  areas. 
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3.2. 3. 2. 4  Kernel  Name  to  Pathname  Mapping 
3 . 2 . 3 . 2 . 4 .  1  Users  and  Privileges 

The  use  of  the  Name  Mapping  program  shall  be  restricted  to  the  System 
Operator  because  It  must  access  the  underlying  device  on  which  the  file  system 
is  built. 

3.2. 3. 2. 4.2  Inputs 

The  inputs  to  the  Name  Mapping  program  shall  be  a  list  (possibly  null)  of 
Secure  Entity  IDentlflers  (SEID's)  (the  Security  Kernel  CPCI's  names  for 
objects),  and  the  device  (file  system)  on  which  they  are  to  be  found. 

3. 2. 3. 2. 4. 3  Processing 

If  no  Secure  Entity  Identifiers  have  been  supplied  the  program  shall  pro¬ 
duce  a  list  the  UNIX  path  names  vs.  SEID's  for  all  files  on  the  device-  Other¬ 
wise,  the  list  shall  include  only  the  requested  SEID's 

3. 2. 3. 2. 4. 4  Outputs 

The  outputs  of  the  Name  Mapping  program  shall  be  the  list  of  UNIX  path 
names  vs.  SEID's,  and  diagnostic  information  as  required. 

3. 2. 3. 2. 5  Modify  Control  Entries  for  Filesystem 

3 . 2 . 3 . 2 . 5 • 1  Users  and  Privileges 

The  use  of  the  program  which  can  modify  the  control  entries  for  a  file 
(MCE)  shall  be  restricted  to  the  System  Operator  since  it  requires  access  to  the 
device  on  which  the  file  system  resides.  In  addition,  the  program  should  only 
be  used  by  personnel  with  sufficient  knowledge  of  the  file  system  structure  to 
be  aware  of  exactly  what  may  and  may  not  be  safely  changed. 

3. 2. 3-2. 5. 2  Inputs 

The  inputs  to  MCE  shall  include  the  file  system  to  be  modified,  the  node  to 
be  modified,  and  the  fields  to  be  changed. 

3. 2. 3.2. 5. 3  Processing 

The  MCE  program  shall  modify  the  requested  fields  to  the  requested  value. 
The  program  should  produce  warning  messages  about  how  serious  the  proposed 
modification  may  be. 

3. 2. 3.2. 5.4  Outputs 

The  output  of  MCE  shall  be  the  modified  file  system.  In  addition,  the  file 
system  shall  be  removed  from  the  list  of  acceptable  systems  for  mounting,  forc¬ 
ing  the  Immigration  Officer  Process  (3. 1.4. 4. 4)  to  be  invoked  before  the  file 
system  may  be  mounted.  Finally,  the  program  shall  produce  audit  records  of  its 
use. 
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3 . 2 . 3 • 3  KSOS  System  Generation 

Each  KSOS  Installation  can  be  expected  to  have  a  unique  hardware  configura¬ 
tion.  Due  to  the  requirement  that  KSOS  must  support  a  variety  of  devices,  it  is 
not  practical  to  distribute  a  single  "universal"  copy  of  the  system.  Rather, 
each  site  will  generate  a  system  tailored  to  its  hardware  configuration. 

3. 2. 3. 3.1  Users  and  Privileges 

The  System  Generation  mechanism  shall  be  designed  to  be  used  by  an  indivi¬ 
dual  with  minimal  computer  system  expertise  (e.g.,  the  Security  Officer  who  must 
certify  the  resulting  system).  The  function  shall  possess  no  special  privileges. 
However,  it  must  be  recognized  that  access  to  the  KSOS  system  image  as  it  is 
being  built  is  tantamount  to  being  able  to  violate  all  the  rules  of  the  system. 

3. 2. 3. 3. 2  Inputs 

The  KSOS  system  shall  be  distributed  as  a  three-component  package.  The 
first  component,  a  distribution  tape,  shall  contain  a  starter  system  and  stan¬ 
dard  system-build  libraries  to  be  copied  to  the  target  system  disk  at  the  remote 
site.  Documentation  for  KSOS  shall  comprise  the  second  component  of  the  distri¬ 
bution.  The  third  element  of  the  distribution  package  shall  consist  of  the  sys¬ 
tem  generation  instructions  and  generation  password  sequence.  The  distribution 
tape  and  generation  package  shall  be  transmitted  separately  as  SECRET-level 
material.  The  distribution  tape  will  normally  be  sent  to  the  site  manager, 
while  the  installation  guide  and  passwords  will  be  sent  to  the  System  Security 
Officer. 

A  checksum  technique  shall  be  used  to  validate  transfer  of  the  Kernel  com¬ 
ponents  during  the  system  build  cycle-  Each  copy  of  the  Kernel  modules  shall 
have  a  unique  identifier  (probably  derived  from  the  target  machine's  serial 
number)  that  will  generate  unique  module  checksums  for  each  distribution  tape. 
Each  element  in  the  distributed  system  shall  contain  a  component  checksum.  An 
interactive  system-build  program  shall  compute  the  checksum  associated  with  each 
component,  notifying  the  system  builder  (Security  Officer)  of  the  checksum 
failure  and  identifying  the  failed  component.  As  a  general  rule,  systems  built 
from  "failed"  modules  cannot  be  certified  as  multi-level  secure.  Using  these 
concepts,  the  required  integrity  can  be  provided  to  remotely  generated  systems 
without  requiring  the  System  Security  Officer  to  be  a  system  programmer. 

The  standard  KSOS  distribution  tape  shall  contain  a  bootstrap  loader,  a 
site-specific  starter  system  used  to  generate  the  target  KSOS  system  and  aj.1 
modules  required  to  generate  a  KSOS  system,  at  a  remote  site. 

3. 2. 3. 3. 3  Processing 
3. 2. 3. 3. 3.1  Bootstrap 

The  bootstrap  loader  shall  be  the  first  entry  on  the  KSOS  distribution 
tape.  A  small  program  entered  from  the  machine  console  (or  executed  from  a 
standard  ROM  loader)  shall  read  the  bootstrap  which  shall,  in  turn,  read  the 
starter  system  from  the  tape,  and  then  transfer  control  to  the  starter  system. 
Each  of  the  tape-based  programs  shall  be  checksummed  to  detect  media  failure. 
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3.2. 3. 3. 3. 2  Starter  System 

The  starter  system  shall  be  a  KSOS  system  previously  generated  for  a  par¬ 
ticular  minimum  configuration-  The  starter  system  shall  require  no  more  than 
the  minimum  hardware  specified  in  the  System  Specification  (Type  A).  The  star¬ 
ter  system  may  be  specific  to  a  particular  hardware  configuration.  When  the 
distribution  tape  is  generated  by  the  maintenance  and  support  organization,  the 
appropriate  starter  system  shall  be  selected.  Alternatively,  the  distribution 
tape  may  contain  starter  systems  for  several  common  configurations.  The  device 
and  vector  addresses  of  the  disk  drive  and  console  shall  have  standard  values. 
Any  other  configuration  shall  be  handled  as  a  special  case  by  the  maintenance 
and  support  organization. 

3. 2. 3. 3. 3. 3  Libraries 


The  starter  system  shall  transfer  the  KSOS  system  programs,  libraries,  and 
archives  from  the  distribution  tape  to  the  specified  system  disk  to  complete  the 
system  restoration  process.  Media  failures  should  be  detected  through  component 
checksums . 


3. 2. 3. 3. 3. 4  Special  Cases 


Unique  configurations  with  no  magnetic  tape  or  non-standard  system  disks  or 
console  addresses  shall  be  handled  as  special  cases.  Installations  without  tape 
drives  shall  receive  a  disk-based  distribution  of  KSOS. 

3. 2. 3. 3. 3. 5  System  Generation 

System  generation  is  basically  a  matter  of  selectively  including  the 
appropriate  device  drivers  in  the  Security  Kernel,  defining  the  /dev  files  and 
their  underlying  Kernel  representations  and  "binding”  the  /dev  files  to  the 
Kernel's  assignment  structure.  The  remainder  of  the  system  software  may  require 
minor  local  (per  site)  modifications,  for  example  to  set  the  local  time  zone. 
All  such  common  local  modifications  shall  be  automated  through  the  use  of  shell 
scripts  or  other  equivalent  mechanisms. 

The  Security  Officer  will  execute  an  interactive  System  Configurator  pro¬ 
gram  similar  to  mkconf(VHl)  [Thompson  75]  for  standard  UNIX.  The  System  Confi¬ 
gurator  program  may  be  executed  under  the  starter  system  or  under  a  larger  KSOS 
configuration.  The  Security  Officer  shall  interact  with  the  program  to  define 
the  hardware  configuration  for  which  the  KSOS  system  is  to  be  generated.  A  list 
of  hardware  parameters  (e.g.,  in  the  PDP-11 /70  version,  base  address  of  the  con¬ 
trol  and  status  registers,  vector  addresses,  and  interrupt  priorities)  must  be 
provided  to  the  Security  Officer  by  a  knowledgeable  individual.  A  "standard" 
list  shall  be  provided  in  the  installation  instructions. 

The  System  Configuration  dialogue  shall  allow: 

a.  selection  of  devices. 

b.  specification  of  device  control  registers,  and  vector  addresses,  and  inter¬ 
rupt  priority  levels. 
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c-  device  driver  source/entry  names- 

The  System  Configurator  program  shall  prompt  with  "standard"  device  infor¬ 
mation,  unless  a  local  configuration  file  is  specified.  In  that  case,  the  Confi¬ 
gurator  program  shall  be  used  to  create  an  updated  (new)  configuration  file- 
The  new  configuration  file  shall  be  checked  for  consistency,  and  then  used  to 
generate  the  "new"  local  system  by  comparison  of  the  new  and  old  configurations. 
Any  changes  shall  cause  the  appropriate  drivers  to  be  edited,  recompiled,  check- 
summed,  and  archived.  Appropriate  controls  on  use  of  the  Configurator  program 
must  be  observed,  since  portions  of  the  Security  Kernel  will  have  to  be  recom¬ 
piled  to  change  device  register  addresses. 

3. 2. 3. 3. 3. 6  Integrity  of  the  Inputs 

The  configuration  procedure  shall  execute  the  internal  program  that  vali¬ 
dates  the  checksum  of  each  of  the  modules  required  in  the  link  edit  phase.  In 
the  event  of  a  checksum  error,  the  failed  modules  shall  be  identified  to  the 
system  builder  (Security  Officer).  If  any  checksum  failures  are  noted,  the  sys¬ 
tem  shall  not  be  certified  as  being  suitable  for  multi-level  secure  operation. 

3. 2. 3. 3. 3. 7  Rename  System 

The  final  operation  of  the  configuration  procedure  shall  give  the  system 
its  bootstrap  name,  e.g.  KS0S-1.0.  This  step  should  not  occur  if  any  errors 
(e.g.,  checksum  errors)  have  occurred-  This  procedure  is  executed  prior  to  the 
Security  Officer  bootstrapping  up  the  new  version  of  the  KSOS  system.  For  addi¬ 
tional  security  and  integrity  it  is  recommended  that  sites  do  not  leave  the 
sources  for  the  trusted  software  on  normally  on-line  disks. 

3. 2. 3. 3- 3. 8  System  Regeneration 

When  new  hardware  is  added  to  a  configuration,  the  system  will  need  to  be 
"regenerated"  to  reflect  the  changes.  This  regeneration  process  should  be  car¬ 
ried  out  by  the  Security  Officer  in  a  single-user  environment.  By  using  the 
Configurator  program  in  an  update  mode,  only  new  information  or  changes  will 
need  to  be  entered  to  create  the  new  system  configuration.  While  the  procedure 
could  easily  be  carried  out  in  a  multi-user  environment,  single-user  operation 
appears  to  be  an  appropriate  mode  of  operation  during  system  regeneration  of 
KSOS . 


3. 2-3. 3. 4  Outputs 

The  output  of  the  system  (re) generat ion  process  shall  be  a  "bootstrappable" 
KSOS  image,  and  any  diagnostic  or  status  information  required. 

3.2.4  System  Administration  Services 

3.2.4. 1  User  Control  Editor 

The  User  Control  Editor  shall  be  used  by  the  System  Administrator  to  con¬ 
trol  access  to  the  system  by  modifying  the  User  Access  Authentication  Data  Base 
and  the  Group  Access  Authentication  Data  Base. 
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3 . 2 . 4 . 1 . 1  Users  and  Privileges 

Use  of  this  program  shall  be  restricted  to  users  running  at  the  system  high 
security  and  integrity  level  and  in  the  system  compartment. 

This  process  shall  be  privileged  to  issue  K_secure_terminal_lock  calls. 

3. 2.4. 1.2  Inputs 

The  User  Control  Editor  shall  receive  input  from  the  Administrator  via  the 
secure  path.  It  shall  have  read/write  access  to  the  User  Access  Authentication 
Data  Base  and  to  the  Group  Access  Authentication  Data  Base.  The  User  Control 
Editor  shall  also  have  read  access  to  the  Security  Map  Data  Base. 

3. 2. 4. 1. 3  Processing 

The  User  Control  Editor  shall  process  requests  from  the  System  Administra¬ 
tor  to  add  and  delete  users,  to  change  a  user's  default  login  level,  to  change  a 
user's  access  level  capabilities,  to  change  a  user's  initial  login  group,  to 
change  user  and  group  passwords,  and  to  assign  Group  Administrators.  Appropri¬ 
ate  checks  shall  be  made  by  the  process  to  assure  data  base  integrity.  Audit 
messages  shall  be  generated  and  sent  to  the  Audit  Capture  Process. 

3.2.4. 1.4  Outputs 

The  User  Control  Editor  shall  send  such  messages  as  necessary  to  the  user 
terminal  via  the  secure  terminal  path.  It  shall  also  make  changes  as  necessary 
to  the  User  Access  Authentication  Data  Base  and  the  Group  Access  Authentication 
Data  Base.  In  addition,  it  shall  generate  and  send  to  the  Audit  Capture  Process 
necessary  audit  trail  messages. 

3. 2. 4. 2  Audit  Capture  Process 

The  Audit  Capture  Process  shall  be  a  system  process  which  receives  audit 
messages  and  writes  them  onto  a  accounting  file- 

3. 2. 4. 2. 1  Users  and  Privileges 

The  Audit  Capture  Process  shall  be  a  system  process  having  no  direct  users. 

3.2. 4. 2. 2  Inputs 

The  Audit  Capture  Process  shall  receive  accounting  information  from  the 
Kernel  and  NKSR  processes  via  the  inter-process  communication  mechanism  and  the 
signal  mechanism.. 

The  Audit  Capture  Process  shall  accept  messages  Sent  through  the  signal 
mechanism  from  processes  running  at  OPERATOR  integrity  level  or  higher  to  exe¬ 
cute  Certain  System  Operator  commands. 
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3. 2. 4. 2. 3  Processing 

All  messages  received  by  the  Audit  Capture  Process  shall  be  marked  as  to 
whether  they  were  sent  using  the  signal  mechanism  or  the  Inter-process  communi¬ 
cations  mechanism.  The  message  type  shall  then  be  checked  to  determine  if  the 
type  Is  valid.  The  Information  may  be  reformatted  and  additional  information 
such  as  a  time  stamp  added  before  the  message  Is  written  on  the  accounting  file. 

The  Audit  Capture  Process  shall  accept  requests  from  the  System  Operator  to 
switch  accounting  files. 

3. 2. 4. 2. 4  Outputs 

After  processing,  accounting  records  shall  be  written  on  the  audit  file* 

3. 2. 4. 3  Privilege  Control  Process 

The  Privilege  Control  Process  shall  provide  the  Security  Officer  with  the 
ability  to  to  grant  and  revoke  special  privileges  to  processes. 

3. 2. 4. 3-1  Users  and  Privileges 

The  Privilege  Control  Process  shall  be  a  restricted  use  process  run  by  the 
System  Administrator  at  system  high  security  and  integrity  level  and  In  the  sys¬ 
tem  compartment. 

The  Privilege  Control  Process  shall  have  the  ability  to  violate  the  *- 
property  for  security  and  Integrity,  and  discretionary  access. 

3. 2.4. 3. 2  Inputs 

The  Privilege  Control  Process  shall  receive  input  from  the  Security  Officer 
via  the  terminal.  It  shall  also  be  able  to  obtain  status  Information  on  flies. 

3. 2. 4. 3. 3  Processing 

The  Privilege  Control  Process  shall  receive  requests  from  the  System  Secu¬ 
rity  Officer  to  grant  and  revoke  special  privileges  to  processes  by  changing 
elements  of  the  object  type  dependent  information  for  the  file  from  which  the 
process  Is  Invoked. 

3. 2. 4. 3. 4  Outputs 


The  process  shall  write  to  the  Security  Officer  via  the  secure  terminal 
path.  It  shall  change  file  status  information  as  necessary.  The  Privilege  Con¬ 
trol  Process  shall  also  send  audit  messages  as  necessary. 

3. 2. 4. 4  Immigration  Officer  Process 

The  Immigration  Officer  Process  shall  maintain  a  data  base  of  file  systems 
may  which  be  mounted  on  the  system. 
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3. 2.4.4. 1  Users  and  Privileges 

The  Immigration  Officer  Process  shall  be  a  restricted  use  process  and  can 
be  run  only  by  a  user  at  the  ADMINISTRATOR  integrity  level. 

The  Immigration  Officer  Process  shall  have  the  permissions  needed  to  access 
the  underlying  disk  devices. 

3. 2. 4. 4. 2  Inputs 

The  inputs  to  the  Immigration  Officer  Process  shall  consist  of  the  current 
version  of  the  mountable  file  systems  data  base,  parameters  which  specify  which 
file  system  is  to  be  immigrated,  and  the  data  making  up  the  file  system. 

3-2. 4. 4. 3  Processing 

The  Immigration  Officer  Process  shall  check  that  no  privileged  software 
resides  on  the  volume.  The  development  contractor  may  include  additional  checks. 
If  all  checks  are  successful,  the  program  shall  perform  any  remapping  of  secu¬ 
rity  level  representations  that  has  been  requested.  The  Immigration  Officer 
shall  first  check  that  the  proposed  remapping  is  valid:  e.g.,  that  this  system 
includes  all  of  the  access  levels  represented  on  the  foreign  file  system.  If 
all  the  checks  and  the  remapping  (if  required)  are  successful,  the  immigration 
officer  data  base  shall  be  updated  to  reflect  the  fact  that  the  volume  is 
acceptable  for  mounting. 

3.2. 4. 4. 4  Outputs 

The  outputs  of  the  Immigration  Officer  Process  shall  be  the  updated  immi¬ 
gration  officer  data  base  and  any  diagnostic  messages  required. 

3-2.5  Special  Requirements 

3*2. 5.1  Human  Performance 


This  paragraph  is  not  applicable  to  this  specification. 

3. 2. 5. 2  Government  Furnished  Property  List 

The  compiler  used  for  the  Non-Kernel  Security  Related  Software  may  be  fur¬ 
nished  by  the  Government. 

3*  3  Adaptation 

The  Non-Kernel  Security  Related  Software  should  require  no  per-site  modifi¬ 
cation.  Individual  sites  may,  however,  modify  the  non-trusted  functions  as  they 
see  fit.  Field  maintenance  of  the  trusted  functions  shall  be  prohibited  unless 
subject  to  the  quality  assurance  procedures  (e.g. formal  specification,  verifica¬ 
tion,  etc)  equivalent  to  its  initial  creation. 
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4.  QUALITY  ASSURANCE  PROVISIONS 
4. 1  Introduction 


The  underlying  philosophy  of  KSOS  quality  assurance  is  to  provide  a  con¬ 
vincing  demonstration  of  the  security  and  completeness  of  the  system.  Testing 
and  quality  assurance  are  a  complement  to  the  formal  verification  aspects  of 
KSOS.  All  testing  on  KSOS  shall  be  conducted  at  the  development  contractor's 
facility . 

KSOS  shall  be  subject  to  the  technical  reviews  and  audit  procedures  of 
MIL-STD-1 52IA,  Appendices  A-F.  The  following  technical  reviews  and  audits  will 
be  conducted: 

a.  System  Requirements  Review  (Appendix  A) 

b.  System  Resign  Review  (Appendix  B) 

c.  Preliminary  Design  Review  (Appendix  C) 

d.  Critical  Design  Review  (Appendix  D) 

e.  Functional  Configuration  Audit  (Appendix  E) 

f.  Physical  Configuration  Audit  (Appendix  F) 

The  Critical  Design  Review  sha. 1  include  a  review  of  any  mathematical 
proofs  showing  that  the  design  meets  the  requirements  of  the  Government  approved 
DoD  security  model. 

The  Functional  Configuration  Audit  shall  be  the  vehicle  for  the  formal 
review  of  the  design  versus  the  mathematical  description.  The  Physical  Confi¬ 
guration  Audit  shall  be  the  vehicle  for  the  formal  review  of  the  "as  built"  com¬ 
puter  programs  versus  both  their  design  and  their  supporting  documentation.  In 
addition,  the  Physical  Configuration  Audit  shall  verify  that  the  implementation 
requirements  of  the  System  Specifications  (Type  A)  have  been  met.  Both  audits 
shall  include  review  of  any  relevant  mathematical  proofs  of  correctness. 

4.1.1  Category  I  Testing 

The  development  contractor  shall  establish  test  plans  to  demonstrate  that 
all  the  requirements  of  Section  3  have  been  met.  Because  this  CPCI  is  composed 
of  a  number  of  autonomous  functions,  the  primary  vehicle  for  this  demonstration 
shall  be  the  Preliminary  Qualification  Tests.  These  tests  shall  be  designed  to 
exercise  all  the  interface  options  for  each  function.  To  the  extent  feasible, 
the  tests  shall  exercise  all  combinations  of  options.  The  tests  shall  include 
sequences  intended  to  fail,  such  as  attempts  to  violate  the  system's  security 
rules  or  to  use  unacceptable  combinations  of  options.  Government  approval  of 
all  test  plans  is  required. 

The  test  sequences  for  trusted  functions  shall  be  designed  with  the  same 
rigor  as  those  for  the  Security  Kernel.  Specifically,  the  test  sequence  should 
attempt  to  assure  that  all  statements  of  the  program  have  been  exercised. 
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The  general  mechanism  for  assuring  that  the  requirements  of  Section  3  have 
been  met  shall  be  a  comparison  of  the  system  "state"  before  and  after  the  func¬ 
tion  has  been  Invoked.  To  ensure  repeatability,  all  testing  shall  be  automated 
If  possible.  Such  automation  may  include  (but  is  not  limited  to)  shell  scripts, 
test  programs,  and  terminal  emulation  by  another  computer  system. 

4.1.2  Category  II  Testing 

The  KSOS  system  shall  be  subject  to  an  overall  system  test  (Category  II)  in 
accordance  with  the  System  Specification  (Type  A)  and  the  development  contract. 
This  Category  II  test  shall  demonstrate  that  the  three  CPCI's  which  make  up  the 
KSOS  system  function  correctly  together.  The  Category  II  testing  shall  attempt 
to  represent  a  typical  user  load  Including  at  least  ten  (10)  on-line  terminals 
and  a  network  connection.  To  the  extent  feasible,  the  Category  II  testing  shall 
also  be  automated  through  the  use  of  shell  scripts,  and  (optionally)  another 
computer  system  emulating  the  terminal  load. 
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Table  II  -  Quality  Assurance 

Assurance  techniques: 

NA  Not  Applicable 

V  Verification 

F  Formal  Specification 

T  Testing 

D  Demonstration 

A  Analysis 

I  Inspection 

Applicable  test  types: 

1  Module  level  testing 

2  Integration  testing 

3  Acceptance  testing 


Requirement 

Assurance 

Techniques 

Test  types 

NA  V  F 

T 

D 

A 

I 

1 

2 

3 

3. 1.1.1. 

X 

X 

X 

X 

X 

X 

X 

3. 1. 1.2. 1. 1. 

X 

X 

X 

X 

X 

X 

X 

X 

3. 1.1. 2. 1.2.- 

X 

X 

X 

X 

X 

X 

X 

X 

3. 1. 1.2. 2.1. 1. 

X 

X 

X 

X 

X 

X 

X 

X 

3.1. 1.2.2. 1.2. 

X 

X 

X 

X 

X 

X 

X 

3. 1.1. 2. 2. 1.3. 

X 

X 

X 

X 

X 

X 

X 

3. 1.1. 2. 2. 2. 

X 

X 

X 

X 

X 

X 

X 

X 

3. 1.1. 2. 2. 3. 

X 

X 

X 

X 

X 

X 

X 

X 

3. 1. 1.2. 2. 4. 

X 

X 

X 

X 

X 

X 

X 

X 

3. 1.1. 2. 2. 5. 

X 

X 

X 

X 

X 

X 

X 

3. 1.1. 2. 2.6. 

X 

X 

X 

X 

X 

X 

X 

3.1. 1.2.4. 1. 

X 

X 

X 

X 

X 

X 

X 

3. 1. 1.2.4. 2. 

X 

X 

X 

X 

X 

X 

X 

3. 1.1. 2. 4. 3. 

X 

X 

X 

X 

X 

X 

X 

3. 1. 1.2. 4. 4. 

X 

X 

X 

X 

X 

X 

X 

3.2.1. 1. 

X 

X 

X 

X 

X 

X 

X 

X 

3.2. 1.2. 

X 

X 

X 

X 

X 

X 

X 

X 

3.2.2. 1. 

X 

X 

X 

X 

X 

X 

X 

X 

3. 2. 2. 2. 

X 

X 

X 

X 

X 

X 

X 

X 

3. 2. 2. 3. 

X 

X 

X 

X 

X 

X 

X 

X 

3. 2. 2. 4. 

X 

X 

X 

X 

X 

X 

X 

X 

3. 2. 2. 5. 

X 

X 

X 

X 

X 

X 

X 

3. 2. 2. 6. 

X 

X 

X 

X 

X 

X 

X 

3. 2. 3. 1.1. 

X 

X 

X 

X 

X 

X 

X 

3. 2. 3. 1.2. 

X 

X 

X 

X 

X 

X 

X 

3. 2. 3.2.1. 

X 

X 

X 

X 

X 

X 

X 

3. 2. 3. 2. 2. 

X 

X 

X 

X 

X 

X 

X 

3. 2. 3. 2. 3. 

X 

X 

X 

X 

X 

X 

X 

3. 2. 3. 2. 4. 

X 

X 

X 

X 

X 

X 

X 

3. 2. 3. 2. 5. 

X 

X 

X 

X 

X 

X 

X 

3. 2. 3. 3. 

X 

X 

X 

X 

X 

X 

X 
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3.2.4. 1. 

X 

X 

X 

X 

X 

X 

X 

3. 2. 4. 2. 

X 

X 

X 

X 

X 

X 

X 

3. 2. 4. 3. 

X 

X 

X 

X 

X 

X 

X 

3. 2. 4. 4. 

X 

X 

X 

X 

X 

X 

X 
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•  PREPARATION  FOR  DELIVERY 

This  section  is  not  applicable  to  this  specification. 
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6.  NOTES 


This  section  Is  not  applicable  to  this  specification. 
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Appendix  A:  MAJOR  CHANGES  TO  THE  DESIGN 

The  main  body  of  this  document  outlines  the  Intended  design  of  the  NKSR 
portion  of  KSOS .  During  the  implementation  process,  however,  some  aspects  of 
the  design  have  changed.  This  appendix  gives  a  brief  outline  of  the  major 
changes  In  the  design-  Comments  are  given  below  by  CPC  and  are  In  order  of  the 
CPC  number. 

The  basic  combined  functionality  for  the  Secure  Initiator  (CPC  3.1.1)  and 
the  Secure  Server  (CPC  3.1-2)  has  not  changed  between  the  previous  version  of 
the  B5's  and  the  current  version.  This  functionality,  however,  was  repropor¬ 
tioned  between  the  two  processes  and  the  B5  sections  were  written  to  reflect 
this  change. 

At  this  time,  Login  (CPC  3.1.3)  does  not  have  the  mechanism  for  locking  out 
terminals . 

The  Password  Modification  Function  (PMF),  like  Login  and  Logout,  shall  be 
contained  within  the  code  of  the  Secure  Server.  This  function,  however,  Is  not 
currently  implemented. 

Level  Preserving  Copy  (CPC  3.1.8)  and  Level  Preserving  Print  (CPC  3-1.9) 
are  implemented  but  not  yet  debugged  or  tested. 

The  status  of  the  Network  Daemon  (CPC  3.2.1)  can  be  found  In  the  final 
report  for  KSOS. 

Some  changes  were  made  to  the  checks  Mount  (CPC  3.2.5)  performs.  Mount  now 
checks  that  the  mount  on  entry  has  not  been  mounted  on  already.  The  other 
change  Is  that  when  Mount  checks  (using  SMXflow)  that  the  user  has  flow,  in  the 
case  of  security,  to  the  file  system  to  be  mounted.  In  the  case  of  Integrity, 
the  flow  check  is  made  as  If  the  user  had  the  privilege  to  violate  the  Integrity 
*-property . 

System  Shutdown  (CPC  3.2.8)  has  not  been  implemented.  Currently  shutdown 
consists  of  pressing  the  halt  switch. 

Secure  Mail  (CPC  3.2.9)  needs  to  be  redesigned  to  take  into  account  changes 
made  to  the  Kernel  design  (in  particular,  those  changes  dealing  with  the  set  uid 
problem) . 

The  B5's  for  the  UNIX  Directory  Manager  (CPC  3.2.11)  are  located  in  the 
emulator  B5's  for  historical  reasons. 

Make  File  System  (or  File  System  Initialization)  (CPC  3.3.3)  is  Implemented 
as  three  programs:  the  Pack  Initialization  program  (PKI),  the  Extent  Initializa¬ 
tion  program  (EXI),  and  the  Boot  Copy  program  (BTCP). 

The  Directory  Consistency  Check  (CPC  3.3.4)  and  the  Kernel  Name  to  Pathname 
Mapping  (CPC  3.3.6)  have  not  been  implemented. 

Modify  File  System  Control  Entry  (CPC  3.3.7)  does  not  print  warning  mes¬ 
sages  Indicating  the  seriousness  of  the  proposed  changes.  It  also  does  not 
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remove  the  fiie  system  from  the  immigration  officer  data  base.  If  this  function 
were  to  be  implemented,  it  could  cause  problems  when  trying  to  make  modifica¬ 
tions  to  the  root  file  system.  The  problem  lies  in  the  fact  that  the  root  file 
system  must  be  mounted  to  run  the  immigration  officer  and  to  access  the  immigra¬ 
tion  officer  data  base. 

The  User  Control  Data  Base  Editor  (CPC  3.4.1)  is  implemented  as  two  pro¬ 
grams:  a  program  to  change  user  information,  and  a  program  to  change  group 
information.  Also,  there  is  no  K_secure_terminal_lock_call  as  is  mentioned. 

At  this  time,  all  messages  sent  to  the  Audit  Capture  Process  (3.4.2)  are 
kept.  They  are  not  marked  as  to  whether  they  were  sent  via  the  signal  mechanism 
or  the  inter-process  communication  (ipc)  mechanism.  In  addition,  the  messages 
are  not  reformatted,  though  a  time  stamp  is  appended. 

A  program  called  the  Audit  Capture  Operator  Interface  (ACP_OP)  is  used  to 
send  messages  from  the  Operator  to  the  Audit  Capture  Process.  These  messages 
cause  the  Audit  Capture  Process  to  report  the  name  of  the  current  audit  file,  to 
switch  to  a  new  audit  file,  or  to  place  the  audit  messages  out  on  the  console 
instead  of  a  file  (or  vice  versa).  In  addition,  the  interface  will  remove  or 
print  any  audit  file  Indicated.  When  printing  the  audit  file,  the  interface 
will  format  the  messages  in  a  readable  form. 

Th«  Privilege  Control  Process  (CPC  3.4.3)  has  not  been  implemented.  Its 
functionality,  however,  is  performed  by  the  Modify  File  System  Control  Entry 
(CPC  3.3.7). 

The  list  of  possible  privileges  which  could  be  given  or  withdrawn  by  the 
process  has  changed.  Below  is  a  brief  description  of  each  privilege  currently 
permitted: 

a.  The  ability  to  violate  the  simple  security  property.  (This  privilege  is 

not  intended  to  be  used.  Originally,  it  was  include  merely  for  complete¬ 

ness.  It  was  found,  however,  to  be  useful  during  implementation  to  circum¬ 
vent  certain  types  of  bugs  and  allow  development  to  continue  without  having 
to  wait  for  the  bug  to  be  fixed.) 

b.  The  ability  to  violate  the  simple  integrity  property. 

c.  The  ability  to  violate  the  *-property  for  security. 

d.  The  ability  to  violate  the  ^-property  for  integrity. 

e.  The  ability  to  violate  the  security  compartments. 

f.  The  ability  to  violate  discretionary  access. 

g.  The  ability  to  use  the  K__link  and  K_unlink  primitives. 

h.  The  ability  to  use  the  Kjnount  and  K_unmount  primitives. 

i.  The  ability  to  change  the  following  pieces  of  type  independent  information 
about  an  object. 
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1.  The  security  level  of  the  object- 

2.  The  integrity  level  of  the  object- 

3-  The  security  compartments  of  the  object- 

4.  The  owner  of  the  object- 

5.  The  group  of  the  object- 

j.  The  ability  to  save  the  process  image  in  the  swapping  area- 

k.  The  ability  to  lock  a  segment  in  core- 

1-  The  ability  to  use  the  K_signal  primitive- 

m.  The  ability  to  use  the  K_halt  primitive. 

n-  The  ability  to  do  volume  valids  through  the  K_device_function  primitive- 

o.  The  ability  to  walk  through  the  process  table. 

p.  The  ability  to  use  the  execute  bit  to  determine  if  one  has  read  access  to 

the  object  (used,  for  example,  when  searching  directory  structures). 

q.  The  ability  to  change  the  terminal  path. 

r.  The  ability  to  change  characteristics  of  a  terminal;  e-g-,  the  speed  or  the 

parity  of  a  terminal- 

s.  The  ability  to  grant  or  revoke  privileges  using  the  K_set_priv  primitive. 

The  Immigration  Officer  Process  (CPC  3.4.4)  is  not  implemented  in  full-  It 
was  planned  to  take  the  File  System  Restore  program  (CPC  3-2-2)  and  add  the 
necessary  checks  of  the  file  system  and  the  handling  of  the  immigration  officer 
data  base  to  it. 
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1  $("  MODULE 

2 

3 

4 

5  CONTENTS 

6  TYPE 

7  LAST  CHANGED 

8  ") 

9 

10  MODULE  SOS 

11  TYPES 

12 


System  Operation  Services  Specs 
(Version  1.8,  11:48:07) 

Module  Name  (NSO. specs) 

File  Name  (/kr /sunix/specs/nksr /s . NSO . specs) 
Assign,  Deassign,  Mount,  Unmount 
SPECIAL. specifications 
4/21/81,11:48:07 


13  nonDisType:  STRUCT_0F( 

14  INTEGER  securityLevel ;  SET_0F  securityCat  securityCatS ; 

15  INTEGER  integrityLe vel ;  SET_0F  integrityCat  integrityCatS ) ; 

16  $(integrityCat  is  typically  the  null  set) 

17  daType:  SET0F  daMode ; 

18  modeStruct:  STRUCT_0F(daType  ownerMode,  groupMode,  allMode); 

19  tiiStruct:  STRUCT  OF(nonDisType  nd; 

20  modeStruct  da;  INTEGER  owner,  group;  SETOF  privType  priv); 

21  DBMEentry :  STRUCT_0F(VECT0R_0F  CHAR  fileSysName; 

22  VECTOR  OF  CHAR  mountOnName;  seid  mountOnSeid;  fileNsp  slot; 

23  BOOLEAN  readonly); 

24  $(“In  addition  to  the  above  fields,  the  implementation  also  includes 

25  a  timestamp,  omitted  from  these  specs  for  simplicity, 

26  and  TIIinfo(fileSysName) ,  which  is  omitted  here  since 

27  there  is  no  need  to  include  TIIinfo()  as  a  specific  field 

28  in  a  STRUCT  within  the  specs.") 

29 

30  DDBentry:  SI  P!ioT_OE(  nonO  Is  Type  maxLevel; 

31  BOOLEAN  unloaded, 

32  inUse); 

33 

34  deviceProfileEntry:  STRUCT  0F(seid  devSeid;  nonDisType  maxLevel); 

35 

36  $(from  fca) 

37  fileNsp:  {129  ..  255}; 

38  globalData :  STRUCT_0F( INTEGER  linkCount,  openCount,  timeLastMod;  seid  subtype; 

39  BOOLEAN  upenAtCrash) ; 

40  $(state  information  for  all  openable  objects) 

41 

42  mountTableEntry :  STRUCT_0F( seid  rootSeid;  BOOLEAN  readonly; 

43  tiiStruct  devTii;  globalData  devGl); 

44 

45  PARAMETERS 

46 

47  INTEGER  unassignedUserld  $(For  use  by  deassign); 

48  INTEGER  operatorlntegrityLevel ; 

49  INTEGER  maxSizeDBME; 

50  seid  nullSeid: 

51  fileNsp  rootFileNsp;  $(nullSeid  and  rootFileNsp  are  for  initializing  DBME) 

52  SET  OF  deviceProfileEntry  devic.eProfi le ; 

53  $(deviceProfile  is  determined  at  system  generation  time; 

54  for  each  "allowable"  device  devSeid,  it  provides  the  maximum 

55  level  of  the  device.  Used  in  initializing  DDB  below.) 

56  SET  OF  VECTOR  OF  CHAR  DBIOset; 
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57  $(DBIOset  is  determined  at  system  generation  time;  contains 

58  the  name  of  all  extents  that  are  allowed  to  be  mounted.  Used 

59  here  in  initializing  DBIO.) 

60 

61  DEFINITIONS 

62 

63  BOOLEAN  LE(nonDisType  ans,x)  IS 

64  ans . securityLevel  <*  x. securityLevel  AND 

65  ans . securityCatS  SUBSET  x. securityCatS  AND 

66  ans . integrityLevel  <=  x. integrityLevel  AND 

67  ans . integrityCatS  SUBSET  x. integrityCatS ; 

68  $(The  basic  ordering  relation  between  two  nonDisTypes) 

69 

70  EXTERNALREFS 

71 

72  FROM  smx: 

73  INTEGER  SENlowLevel; 

74  INTEGER  SENhighLevel; 

75  seid:  DESIGNATOR; 

76  secureEntityType :  {tFile,  tDevice,  tTerminal,  tProcess,  tSegment,  tSubtype, 

77  tExtent,  tNullj; 

78  prtvType:  { 

79  privFileUpdateStatus ,  privLink,  privLockSeg, 

80  privModifyPriv,  privMount, 

81  privSetFileLevel,  privSetSegProcLevel , 

82  privStickySeg,  privTerminalLock, 

83  privViolSimpSecurity,  privViolStarSecurity, 

84  privViolSimpIntegrity ,  pri vViolStar Integrity , 

85  privViolDiscrAccess ,  privSignal ,  privWalkPTable , 

86  privHalt ,  privKernelCall ,  privViolCompartments , 

87  privRealizeExecPermissions}; 

88 

89  daMode:  {daRead,  daWrite,  daExecute}; 

90  securityCat:  DESIGNATOR; 

91  integrityCat :  DESIGNATOR; 

92  domainType:  {userDomain,  supervisorDomain } ; 

93 

94  VFUN  TIIinfo(seid  s)  ->  tiiStruct  st; 

95  VFUN  SMXf low(seid  pSeid,  oSeid;  daType  da)  ->  BOOLEAN  b;  $(SMXflow) 

96  VFUN  SMXdap( seid  pSeid,  oSeid;  daType  da)  ->  BOOLEAN  b: 

97  VFUN  SENseidNsp( seid  anySeid)  ->  INTEGER  nsp; 

98  VFUN  SENseidToInt (seid  anySeid)  ->  INTEGER  i; 

99  VFUN  SENseidType(seid  s)  ->  secureEntityType  set;  S(SENseidType) 

100  VFUN  SMXhasPriv(seid  pSeid;  privType  privl)  ->  BOOLEAN  b;  $(SMXhasPriv) 

101 

102  FROM  fca: 

103  VFUN  FCAinfo(seid  fSeid)  ->  globalData  gl:  $(FCAinfo) 

104  VFUN  FCAmountTable(f ileNsp  nsp)  ->  mountTableEntry  mte;  $(FCAmountTable) 

105 

106  FROM  udm: 

107  0FUN  mount(seid  pdirSeid , nspSeid ;  VECT0R_0F  CHAR  name); 

108  0FUN  unmount (seid  pdirSeid;  VECT0R_0F  CHAR  name); 

109 

110  FROM  ker: 

111  0VFUN  K_mount(seid  dev;  BOOLEAN  readonly)  ->  fileNsp  newNsp;  $(K_mount) 

112  0FUN  K  unmount(seid  devSeid); 
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113 

114 

115 

116  FUNCTIONS 

117 

118  $( -  VFUNS  - ) 

119  VFUN  DDB(seid  dSeld)  ->  DDBentry  ans; 

120  $(Device  Data  Base) 

121  HIDDEN; 

122  INITIALLY 

123  ans  « 

124  (LET  de vlceProf 1 leEntry  x  |(  x  INSET  deviceProfile 

125  AND  x. devSeid  -  dSeld) 

126  IN 

127  IF  x  ? 

128  THEN 

129  STRUCT ( x. raaxLe vel ,  FALSE,  FALSE) 

130  ELSE 

131  ?); 

132 

133  VFUN  DBIO ( )  ->  SETjOF  VECTOROF  CHAR  ans; 

134  $(Data  Base  Immigration  Officer  -  The  name  of  the  extent  ycu 

135  are  trying  to  mount  in  nksrMount  must  be  in  DBIO) 

136  HIDDEN; 

137  INITIALLY 

138  ans  ■  DBIOset; 

139 

140  VFUN  DBME()  ->  SET_OF  DBMEentry  ans; 

141  $(Data  base  of  mounted  extents. 

142  Initialized  in  the  implementation  by  Secure  Initiator;  the  specs 

143  below  simulate  this  initialization.  Entries  are  added 

144  by  nksrMount,  deleted  by  nksrUnmount) 

145 

146  HIDDEN; 

147  INITIALLY 

148  ans  -  {STRUCT( 

149  "/",  $(root  fileSysName) 

150  $(null  mountOnName) 

151  nullSeid,  $(null  mountOnSeid) 

152  rootFileNsp, 

153  FALSE 

154  )}; 

155 

156 

157  $( -  0FUNS  - ) 

158 

159 

160  OFUN  assign(seid  devSeid )[ seid  pSeid]; 

161 

162  DEFINITIONS 

163  tiiStruct  ptii  IS  Tllinfo(pSeid) ; 

164 

165  EXCEPTIONS 

166  notDevice:  SENseidType(devSeid)  tDevice; 

167  badDev:  DDB(devSeid)  >  ?; 

168  badLevel:  NOT  LE(ptii .nd , DDB(devSeid) .maxLevel ) ; 
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169  inUse:  DDB(devSeld) . inUse ; 

170 

171  EFFECTS 

172  'TIIinfo(devSeid)  -  STRUCT ( 

173  ptii.nd, 

174  STRUCT( {daRead , daWrite },{},{}) ,  $(read/write  by  owner  only) 

175  SENseidToInt(pSeid) ,  $(new  owner  is  pSeid) 

176  ptli. group, 

177  ptii.priv); 

178  'DDB(devSeid)  -  STRUCT ( 

179  DDB(devSeid ). maxLevel , 

180  TRUE,  $(device  Is  now  "unloaded") 

181  TRUE);  $(device  is  now  in  use) 

182 

183  OFUN  deassign(seid  devSeid)  [seid  pSeid]; 

184 

185  DEFINITIONS 

186  tiiStruct  dtii  IS  Tllinfo(devSeid); 

187  tiiStruct  ptii  IS  Tllinfo(pSeid) ; 

188 

189  EXCEPTIONS 

190  notDevice:  SENseidType(devSeid)  tDevice; 

191  badDev:  DDB(devSeid)  =  ?; 

192  badOwner:  dtii. owner  SENseidToInt (pSeid)  AND 

193  ptii . nd . integrityLevel  <  operator IntegrityLevel; 

194  $(Either  the  invoking  process  owns  the  device,  or  is 

195  at  or  above  operator  integrity  level) 

196 

197  EFFECTS 

198  'TIIinfo(devSeid)  »  STRUCT( 

199  STRUCT (SENhighLevel , { } , SENhighLevel ,  { }) , 

200  STRUCT( {},{},{}), 

201  unassignedUserld , 

202  unassignedUserld, 

203  {} 

204  ); 

205 

206  'DDB( devSeid)  -  STRUCT ( 

207  DDB(devSeid) .maxLevel , 

208  DDB(devSeid) .unloaded , 

209  FALSE 

210  ); 

211 

212  OFUN  nksrMount(  VECT0R_0F  CHAR  mountFromName; 

213  seid  mountFromSeid; 

214  VECT0R_0F  CHAR  mountOnName; 

215  seid  mountOnSeld; 

216  BOOLEAN  readonly 

217  )  [seid  pSeid] ; 

218 

219  $(The  parameters  mountFromSeid  and  mountOnSeid  are  given  explicitly 

220  in  these  specs  for  convenience.  In  the  implementation,  these  seids 

221  are  determined  from  mountFromName,  drive  number,  and  mountOnName  resp.) 

222 

223  $( "Between  the  kernel  and  the  nksr,  there  are  three  mount  functions. 

224  K-mount  performs  physical  mounting;  mount  in  the  directory  manager 
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225  performs  a  simple  mapping  in  the  directory  VFUN-  the  present 

226  nksrMount  utilizes  the  functionality  of  the  other  two  mounts. 

227  As  a  result  of  nksrMount,  an  extent  is  now  interpreted  as  a  file  system 

228  bv  the  directory  manager.") 

229 

230  DEFINITIONS 

231  fileNsp  openSlot  IS 

232  SOME  fileNsp  freeMountNsp  I  FCAmountTable(freeMountNsp)“?; 

233  S(openSlot  simulates  the  value  returned  by  K_mount; 

234  the  related  value  nspSeid,  defined  next,  is  used  in  the 

235  "call"  to  mount  in  the  EFFECTS  section  below.) 

236 

237  seid  nspSeid  IS 

238  SOME  seid  s  I  SENseidNsp(s)  «  openSlot; 

239  $(Need  a  seid,  rather  than  simply  an  nsp  component  to  pass  to  mount) 

240 

241  EXCEPTIONS 

242  alreadyMounted :  EXISTS  DBMEentry  x  INSET  DBME()  : 

243  x. fileSysName  »  mountFromName ; 

244  badExtent:  NOT  mountFromName  INSET  DBI0():  $(The  extent  you  are  trying 

245  to  mount  must  be  in  the  Immigration  Officer  database,  DBIO) 

246  DBMEfull :  CARDINALITY(DBME() )  -  maxSizeDBME; 

247  badRWAccess:  NOT  readonly  AND  NOT  SMXf low( pSeid,  mountFromSeid , 

248  { daRead, daWrite } ) : 

249  badRAccess :  readonly  AND  NOT  SMXf low(pSeid .mountFromSeid , {daRead }) ; 

250  badWAccess:  NOT  SMXf low(pSeid ,  mountOnSeid,  {daWrite}): 

251  badRWdap:  NOT  readonly  AND  NOT  SMXdap(pSeid,  mountFromSeid, 

252  {daRead, daWrite}); 

253  badRdap:  readonly  AND  NOT  SMXdap(pSeid .mountFromSeid, {daRead }) ; 

254  badWdap:  NOT  SMXdap( pSeid,  mountOnSeid,  {daWrite}); 

255  notStarSec:  NOT  SMXhasPriv(pSeid .privViolStar Security ) ; 

256  $(Exceptions  from  FCAmount  follow) 

257  XbadPriv:  NOT  SMXhasPriv(pSeid , pri vMount ) : 

258  XnoFile:  FCAlnfo(mountFromSeid)  *  ?;  $(Successfully  passing  the 

259  badExtent  check  above  implies  that  this  check  will 

260  be  passed  successfully) 

261  XnoClass:  SENseidType(mountFromSeid)  ~m  tExtent ; $(same  comment  as  XnoFile) 

262  XmntSpace :  RES0URCE_ERR0R ; 

263 

264  EXCEPTI0NS0F  mount(mountOnSeid, nspSeid, mountOnName): 

265 

266  EFFECTS 

267  openSlot  -  EFFECTS_0F  K_mount(mountFromSeid, readonly) ; 

268  EFFECTS_OF  mount(mount0nSeid, nspSeid, mountOnName); 

269  'DBME()~-  DBME()  UNION  {STRUCT( 

270  mountFromName, 

271  mountOnName, 

272  mountOnSeid, 

273  openSlot, 

274  readonly 

275  )}; 

276 

277 

278  OFUN  nksrUnmount(seid  fSeid)  [seid  pSeid]; 

279  S(fSeid  corresponds  to  mountOnSeid  from  nksrMount) 

280 
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281  DEFINITIONS 

282  DBMEentry  x  IS  SOME  DBMEentry  y  I  (y  INSET  DBME()  AND 

283  y .mountOnSeid  “  fSeid); 

284  $(It  is  assumed  that  mountOnSeid,  as  a  field  within  DBMEentry, 

285  is  a  key,  i.e.,  uniquely  determines  the  entire  entry  y.) 

286  BOOLEAN  readonly  IS  x. readonly; 

287  fileNsp  fsNsp  IS  x.slot; 

288 

289  EXCEPTIONS 

290 

291  NotalreadyMounted :  x  *  ?; 

292  badWAccess:  NOT  SMXf low(pSeid ,  fSeid,  {daWrite}): 

293  badWdap:  NOT  SMXdap(pSeid ,  fSeid,  {daWrite}); 

294  notStarSec:  NOT  SMXhasPriv(pSeid, privViolStarSecurity) ; 

295  XbadPriv:  NOT  SMXhasPriv(pSeid ,  privMount); 

296  XnoXXX :  FCAmountTable( fsNsp)  -  ?; 

297  XnoTranquil: 

298  EXISTS  seid  fSeid  |  SENseidNsp(fSeid )  -  fsNsp 

299  :  FCAinfo(fSeid) .openCount  >  0; 

300  EXCEPTIONS  OF  unmount ( fSeid,  x. mount OnName ) : 

301 

302  EFFECTS 

303 

304  EFFECTS  OF  K  unmount ( fSeid) ; 

305  EFFECTS_OF  unmount( fSeid ,  x.mountOnName); 

306  'DBMEQ  =  DBME ()  DIFF  {x}; 

307 

308 

309  END  MODULE 
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MODULE 


CONTENTS 
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LAST  CHANGED 


Secure  User  Services  Specs 

Version  (1.7,14:52:13) 

Module  Name  (NSU. specs) 

File  Name  (/kr/sunix/specs/nksr/s . NSU. specs) 
Secure  Server,  Login,  Logout,  ChangeAccess  Level, 
ChangeGroup,  FileAccessModifier 
SPECIAL. specifications 
11/21/80,14:52:13 


MODULE  SUS 


TYPES 


nonDisType:  STRL'CT_0F( 

INTEGER  securityLevel ;  SET_0F  securityCat  securityCatS ; 
INTEGER  integrityLevel;  SET_0F  integrityCat  integrityCatS ) ; 
$( integr ityCat  is  typically  the  null  set) 
daType:  SETOF  daMode: 

modeStruct:  STRUCT_0F( daType  ownerMode,  groupMode,  allMode); 
tiiStruct:  STRUCT  0F(nonDisType  nd; 

modeStruct  da;  INTEGER  owner,  group;  SETOF  privType  priv); 


PARAMETERS 


INTEGER  sysHighLevel  $(Highest  possible  security  and  integrity  level); 
SET_OF  securityCat  allSecCats  $(Full  universe  of  securityCatS)  ; 
SET_0F  integrityCat  alllntCats  $(Full  universe  of  integrityCatS)  ; 


DEFINITIONS 

nonDisType  minimum(SET_OF  nonDisType  sd)  IS 

SOME  nonDisType  ans  I  ans  INSET  sd  AND 

(FORALL  nonDisType  x  INSET  sd: 

ans. securityLevel  <=  x. securityLevel  AND 

(FORALL  securityCat  a  INSET  ans . securityCatS  :  a  INSET 

x. securityCatS )  AND 

ans . integrityLevel  <■  x. integrityLevel) ; 

BOOLEAN  LE(nonDisType  ans,x)  IS 

ans . securityLevel  <»  x. securityLevel  AND 

ans .securityCatS  SUBSET  x. securityCatS  AND 

ans. integrityLevel  O  x. integrityLevel  AND 

ans. integrityCatS  SUBSET  x. integrityCatS ; 

$(The  basic  ordering  relation  between  two  nonDisTypes) 


EXTERNALREFS 

FROM  smx: 
seid:  DESIGNATOR; 
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57  secureEntityType :  {tFile,  tDevlce,  tTerminal,  tProcess ,  t Segment ,  tSubtype, 

58  tExtent,  tNull}; 

59  prlvType:  { 


prlvFlleUpdateStatus , 
prlvModifyPriv, 
prlvSe tFile Level , 
privStickySeg , 
privVlolSimpSecurlty , 
privVlolSimpIntegrity , 
privViolDiscrAccess , 
privHalt , 


privLink,  privLock.' 

prlvMount , 

privSetSegProcLevel , 

privTermlnalLock, 

pr ivViolStar Security , 

privViolStarlntegrity, 

prlvSignal,  privWalkPTable , 

pri vKernelCall ,  privViol Compartments , 


68  privRealizeExecPermlssions} ; 

69 

70  daMode:  {daRead,  daWrite,  daExecute}; 

71  securityCat :  DESIGNATOR; 

72  integrityCat:  DESIGNATOR; 

73  domainType:  {userDomain,  supervisorDomaln} ; 

74 

75  VFUN  TIIlnfo(seld  s)  ->  tilStruct  st; 

76  VFUN  SMXf low(seid  pSeid,  oSeld;  daType  da)  ->  BOOLEAN  b:  $(SMXflow) 

77  VFUN  FCAterminalPathSet (seid  termlnalGroup)  ->  SET_0F  seid  ss ; 

78  VFUN  FCAcurrentPath(seld  teroinalGroup)  ->  seid  s; 

79  $(Note  that  the  parameter  types  of  the  two  FCA  VFUNS  has  been  changed 

80  from  a  separate  DESIGNATOR  type  to  a  seid. 

81  These  changes  must  also  be  made  in  the  kernel  specs.) 

82  VFUN  SENseldNsp(seld  anySeid)  ->  INTEGER  nsp; 

83 

84 

85  ASSERTIONS 

86 

87  TRUE;  $ (Placeholder  for  the  ASSERTIONS  paragraph.) 


ASSERTIONS 


$ (Placeholder  for  the  ASSERTIONS  paragraph.) 


FUNCTIONS 


92  $( - VFUNS - ) 

93 

94  $("The  Important  VFUNS  are: 

95  UAADB  (User  Authentication  Access  Data  Base) 

96  TPDB  (Terminal  Profile  Data  Base) 

97  SDB  (System  Data  Base) 

98  GADB  (Group  Authorization  Data  Base) 

99  FCAterminalPathSet 

100  FCAcurrentPath 

101  terminalUser  (for  a  given  terminal,  tells  the  user,  as  given  by 

102  the  most  recent  Login) 

103  ptbl  (a  table  showing,  for  a  given  process  seid,  the  terminal 

104  and  terminal  path  in  use  by  that  seid) 

105  auditTrail  (for  sending  audit  messages) 

106  securePath  (path  used  when  ATTN  key  is  struck  on  a  terminal) 


111  VFUN  UAADB (VECT0R_0F  CHAR  userName)  ->  STRUCT_0F( 

112  VECTOR  OF  CHAR  password; 
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113  INTEGER  consecutlveUnsuccessfulLogins; 

114  BOOLEAN  loginsPermitted ; 

115  seid  init ialProcess ; 

116  tiiStruct  inlc ialLevel ; 

117  nonDisType  maxLevel)  ans ; 

118  $("Life  cycle  of  UAADB:  login  reads  Che  following: 

119  password,  loginsPermitted,  initialProcess,  init ialLevel ,  maxLevel  ; 

120  login  updates  consecutlveUnsuccessfulLogins") 

121  HIDDEN; 

122  INITIALLY 

123  TRUE; 

124  $(***Perhaps  there  are  some  initial  restrictions?) 

125 

126  VFUN  TPDB(seid  terminalGroup  )  ->  STRUCT_0F( 

127  BOOLEAN  locked, 

128  configured, 

129  loggedln; 

130  nonDisType  maxLevel)  ans  : 

131 

132  $(Life  cycle  of  TPDB:  login  reads  the  following  fields: 

133  locked,  configured,  loggedln,  maxLevel. 

134  changeAccessLevel  reads  maxLevel;  login  updates  loggedln.) 

135 

136  HIDDEN; 

137  INITIALLY 

138  TRUE; 

139 

140  VFUN  SDB ( )  ->  STRUCT_0F( 

141  nonDisType  maxLevel)  x;  $(given  as  STRUCT  to  allow  for  more  fields  later) 

142  $(read  by  changeAccessLevel,  login,  f ileAccessModifier) 

143  HIDDEN; 

144  INITIALLY 

145  TRUE; 

146 

147  VFUN  GADB( INTEGER  x)  ->  STRUCT_0F( 

148  nonDisType  maxLevel; 

149  VECT0R0F  CHAR  password)  y  ; 

150  $(read  by  changeGroup,  changeAccessLevel,  f ileAccessModifier ) 

151  HIDDEN; 

152  INITIALLY 

153  TRUE; 

154 

155  VFUN  terminalUser (seid  terminalGroup)  ->  VECT0R_0F  CHAR  user: 

156  $(initialized  by  login;  finalized  by  logOut;  read  by  f ileAccessModifier) 

157  HIDDEN; 

158  INITIALLY 

159  F0RALL  seid  x  :  terminalUser (x)  «?: 

160 
161 

162  VFUN  ptbl(seid  pSeid)  ->  STRUCT_0F( 

163  seid  t,  $("terminal") 

164  p)  x  ;  $("path  used  by  pSeid  on  terminal  t”) 

165  HIDDEN: 

166  INITIALLY 

167  FORALL  seid  x:  ptbl(x)  »?  ; 

168  $("ptbl  is  initialized  by  the  kernel.  For  simplicity  in  these 
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169  specs,  however,  we  present  only  the  above  initial ' "ation . 

170  ptbl  is  updated  by  login;  read  by  ligCut;  and  *inal*red  by 

171  logOut;  In  the  implementation  there  is  the  addition*,  complexity 

172  that  the  login  process  might  create  new  processes,  which  are 

173  also  added  to  ptbl.  We  ignore  this  complexity  in  thes^  specs”) 

174 

175  VFUN  auditTrail()  ->  VECT0R_0F  VECT0R_0F  CHAR  x; 

176  HIDDEN; 

177  INITIALLY 

178  LENGTH (x)  -0; 

179  $(”auditTrail  is  a  sequence  of  messages  sent  to  the  audit  capture  process. 

180  In  the  implementation,  each  message  is  fixed-length  and  of  a  given 

181  format.  Such  restrictions  are  ignored  here;  the  main  purpose  of 

182  including  auditTrail  in  these  specs  is  to  show  when  such  messages 

183  are  sent") 

184 

185  VFUN  securePath (seid  terminalGroup )  ->  seid  x; 

186  HIDDEN; 

187  INITIALLY 

188  x  INSET  FCAterminalPathSet(terminalGroup) ; 

189 

190  VFUN  charsToInt (VECTOR_OF  CHAR  x)  ->  INTEGER  y; 

191  HIDDEN; 

192  INITIALLY 

193  TRUE; 

194  $(A  minor  conversion  function  used  by  f ileAccessModifier) 

195 

196 

197 

198  $( - OFUNS - ) 

199 

200  $( "Securelnitiator  and  SecureServer  are  not  given  explicitly 

201  in  these  specs.  Instead,  the  main  events  they  handle, 

202  namely,  detecting  that  the  attention  key  is  struck,  detecting 

203  that  a  hangup  has  occurred  destroying  the  physical  connection  between 

204  a  terminal  and  the  cpu,  and  operator  requested  logout  —  are  given 

205  by  the  OFUNS  ATTN,  HANGUP,  and  OPREQLOGOUT.  The  remainder  of  the 

206  functionality  of  the  SecureServer  is  that  of  a  command  interpreter. 

207  In  line  with  the  HDM  model  of  computation,  the  semantics  for  the 

208  individual  commands  is  given  below,  but  the  notion  of  an  explicit 

209  conmand  interpreter  is  not  given.”) 

210 

211  0FUN  ATTN()[seid  terminalGroup]; 

212  $(In  response  to  the  attention  key  being  struck  on  the  terminal) 

213 

214  EFFECTS 

215 

216  'FCAcurrentPath(terminalGroup)  -  securePath( terminalGroup) ; 

217  $("Since  TIIinfo(securePath(t))  never  changes,  there  is  no  need 

218  to  set  it  here.") 

219 

220 

221  0FUN  HANGUP( ) [ seid  terminalGroup]; 

222  $(In  response  to  the  detection  of  a  broken  terminal  connection) 

223 

224  DEFINITIONS 
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seid  t  IS  terminalGroup; 

EXCEPTIONS 

notLoggedln:  NOT  TPDB(t) .loggedln: 

EFFECTS 

FORALL  seid  x  I  ptbl(x).t  <*  t  AND 
ptbl(x).p  securePath ( t)  : 

'TIIinfo(x)  =  ?  AND  'ptbl(x)  =?; 

$(Wipe  out  all  processes  which  are  using  a  non-secure  path  on  the 
effected  terminal.) 

'terminall'serC  t)  »  ?; 

'TPDB(t) .loggedln  -  FALSE; 

FORALL  seid  x  INSET  FCAterninalPathSet(t) : 
x  ~=  secure?ath( t )  => 

'TIIinfo(x)  =?; 

'FCAcurrentPath(t )  =*  ?; 

$(Wipe  out  all  paths,  except  secure  path,  on  the  effected  terminal.) 
OFUN  OPREQLOGOUT(seid  terminalGroup) [seid  pSeid); 


246 

S(Note  that  terminalGroup  is  given  explicitly  for  an  operator 

247 

requested  logout,  in  contrast  to  normal  logout  or  hangup) 

r 

i 

248 

i 

249 

DEFINITIONS 

t 

250 

seid  t  IS  terminalGroup; 

| 

251 

( 

252 

EXCEPTIONS 

253 

notLoggedln:  NOT  TPDB(t) . loggedln; 

254 

badpSeid:  TII inf o( pSeid ). nd  ~=  STRUCT(sysHighLevel ,  allSecCats,  *  SuighLevel, 

255 

alllntCats ) ; 

256 

$(badpSeid  indicates  that  somebody  other  than  the  operator  is  attempting 

257 

to  invoke  0PREQL0G0UT) 

258 

■ 

259 

EFFECTS 

i . 

260 

FORALL  seid  x  I  ptbl(x).t  »  t  AND 

Ik 

261 

ptbl(x).p  ~=»  securePath( t)  : 

262 

'TIIinfo(x)  -  ?  AND  'ptbl(x)  -?; 

i. 

263 

264 

'terminalUser ( t)  m  ?: 

265 

'TPDB(t) .loggedln  -  FALSE; 

k 

266 

FORALL  seid  x  INSET  FCAterminalPathSet(t): 

267 

x  "■  securePath( t)  *> 

268 

'TIIinfo(x) 

r  J 

269 

'FCAcurrentPath( t )  *  ?; 

'  1 

270 

'auditTrailO  -  VECTOR  (FOR  i  FROM  1  TO  LENGTH(auditTrail())+l : 

j 

271 

IF  i  <=  LENGTH  (auditTrailO)  THEN  auditTrailO  [ij 

f  1 

272 

ELSE  "operator  requested  logout"  ); 

:  i 

■4 

273 

'  A 

274 

;  I 

275 

OFUN  logIn(VECT0R  OF  CHAR  userName , password )  [seid  terminalGroup]; 

' 

276 

277 

DEFINITIONS 

1  ! 

278 

seid  t  IS  terminalGroup; 

i 

279 

seid  p  IS  SOME  seid  q  1  q  INSET  FCAterminalPathSet( t)  AND 

[• 

230 

Tllinfo(p)-?; 

I 
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281  $("Note  that  p  cannot  be  securePath(t) “) 

282  tilStruct  s  IS  UAADB(userName) . InitlalLevel ; 

283  nonDisType  ndLevel  IS  minlmum( { 

2  84  s . nd , 

285  TPDB(t) .maxLevel, 

286  UAADB(userName) .maxLevel , 

287  GADB(UAADB( user Name) . InitlalLevel . group) .maxLevel , 

288  SDB() .maxLevel} ); 

289  tiiStruct  startLevel  IS  STRUCT(ndLevel ,  s.da,  s. owner,  s. group,  s.priv); 

290 

291  EXCEPTIONS 

292  badt:  TPDB(t)  =  ?; 

293  badTPDBdata:  TPDB(t) .locked  OR  NOT  TPDB(t) .configured 

294  OR  TPDB(t) .loggedln  OR  NOT  UAADB(userName).loginsPermitted; 

295  undefUser:  L'AADB(  user  Name)  **?; 

296  noPath:  p  =  ? ; 


badLevel:  ndLevel  *?; 


$(This  should  never  happen) 


EFFECTS 

IF  (password  ~=*  UAADB(userName)  .  password )  THEN 
'UAADB(userName)  *  STRUCT(UAADB(userName) .password, 
UAADB(userName) .consecutiveUnsuccessfulLogins  +1 , 

UAADB( user Name) .loginsPermitted, 

UAADB( user Name) .initialProcess, 

UAADB(userName) . initialLevel , 

UAADB( user Name) .maxLevel) 

ELSE 

'UAADB(userName)  ■  STRUCT(UAADB(userName) . password , 

0, 

UAADB(userName) .loginsPermitted, 

UAADB(userName) . initialProcess , 

UAADB (user Name) . initialLevel , 

UAADB(userName) .maxLevel )  AI 

'TIIinfo(p)  »  startLevel  AI 

'TIIinfo(UAADB(userName) .initialProcess)  “  startLevel  AI 

'terminalUser (t)  -  userName  AI 

'TPDB(t) .loggedln  »  TRUE  AI 

'FCAcurrentPath(t)  =  p  AI 

'ptbl(UAADB(userName) .initialProcess)  ■  STRUCT(t,p)  ; 
'auditTrail()  -  VECTOR  (FOR  i  FROM  l  TO  LENGTH (audi t Trail ())+l: 
IF  i  <-  LENGTH(auditTrailO)  THEN  auditTrail()[i] 

ELSE  "login  attempted”  ); 


OFUN  logOut ()[ seid  terminalGroup ] ; 


DEFINITIONS 

seid  t  IS  terminalGroup; 

EXCEPTIONS 

notLoggedln:  NOT  TPDB(t) .loggedln; 
EFFECTS 

FORALL  seid  x  I  ptbl(x).t  -  t  AND 
ptbl(x).p  “»  securePath( t) 
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337  'TIIinfo(x)  -  ?  AND  'ptbl(x) 

338  t  'terminalt'ser(  t)  »  ?; 

339  ‘ 'TPDB(t) .loggedln  -  FALSE; 

340  FORALL  seld  x  INSET  FCAterminalPathSe t (t ) : 

341  x  securePath(t)  => 

342  'TIIinfo(x)  =  ?; 

343 

344  'FCAcurrentPath( t)  =  ?; 

345  'auditTrail()  =  VECTOR  (FOR  i  FROM  1  TO  LENGTH (auditTrail())+l: 

346  IF  i  <=  LENGTH (aud it Trai 1 ( ) )  THEN  auditTrail() [i] 

347  ELSE  "logout"  ): 

348 
3^9 

350  OFUN  changeAccessLevel(seid  terminalGroup ;  tiiStruct  desiredLevel)  ; 

351 

352  DEFINITION'S 

353  seid  t  IS  terminalGroup; 

354  seid  q  IS  SOME  seid  p  I 

355  p  INSET  FCAterminalPathSet (t )  DIFF  {securePath( t) }  AND 

356  Tllinfo(p) .nd  =  desi redLe vel . nd  AND 

357  Tllinfo(p) .owner  =  desiredLevel . owner  AND 

358  Tllinfo(p) .group  =  desiredLevel . group  ; 

359  seid  r  IS  SOME  seid  p  I 

360  p  INSET  FCAtermlnalPathSet(t)  DIFF  (securePath( t ) }  AND 

361  Tllinfo(p)  =  ? ; 

362  r.onDisType  ndLevel  IS  minitnum(  { 

363  TPDB(t) .max Level , 

364  SDB() .maxLevel, 

365  UAADB( terminalUser (t )) .maxLevel, 

366  GADB(TIIinfo(FCAcurrentPath(t)) .group) .maxLevel 

367  }); 

368  tiiStruct  cl  S(current  level)  IS 

369  TIIinfo(FCAcurrentPath(t)) ; 

370  tiiStruct  startLevel  IS  STRUCT (ndLevel , cl . da , cl .owner ,cl . group , cl . priv)  ; 

371 

372  EXCEPTIONS 

373  noPath:  q  *  ?  AND  r  “  ?; 

374  badLevel:  NOT  LE (desi redLevel . nd ,  ndLevel); 

375 

376  EFFECTS 

377  IF  q~«  ?  THEN 

378  'FCAcurrentPath( t)  ■  q 

379  ELSE 

380  'TIIinfo(r)  *  startLevel  AND 

381  'TIIinfo(UAADB(terminalUser (t)) . initialProcess )  **  startLevel  AND 

382  'FCAcurrentPath(t)  *  r  ; 

383  'auditTrailQ  -  VECTOR  (FOR  i  FROM  1  TO  LENGTH (aud it Trai 1())+1: 

384  IF  i  <-  LENGTH(auditTrallO)  THEN  auditTrai  1( ) [ i] 

385  ELSE  "change  access  level"  ); 

386 

387  0FTJN  changeGroup(seid  terminalGroup;  seid  desiredGroup; 

388  VECTOR _0F  CHAR  pwdDesiredGroup)  [seid  pSeid]  ; 

389  $(pSeid  is  the  seid  in  whose  behalf  the  change  is  being  made) 

390 

391  DEFINITIONS 

392  seid  t  IS  terminalGroup; 
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393  CliStruct  ptil  IS  Tllinfo(pSeid) ; 

394  seid  q  IS  SOME  seid  p  I 

395  p  INSET  FCAterminalPathSet(t)  DIFF  { securePath( t ) }  AND 

396  THinfo(p)  .nd  »  TIIinfo(desiredGroup) .nd  AND 

397  Tllinfo(p) .owner  »  TIIinfo(deslredGroup) .owner  AND 

398  Tllinfo(p) .group  «  TIIinfo(deslredGroup) .group  ; 

399  seld  r  IS  SOME  seid  p  I 

400  p  INSET  FCAterminalPathSet(t)  DIFF  {securePath( t ) }  AND 

401  Tlllnfo(p)  =  ? ; 

402  nonDlsType  ndLevel  IS  rainimum( { 

403  TPDB( t) .maxLevel , 

404  SDB( ) .maxLevel , 

405  UAADB( terminalUssr ( t ) )  .maxLevel, 

406  TIIinfo(FCAcurrentPath(t)) -nd 

407  }); 

408  tiiStruct  cl  S(current  level)  IS 

409  TIIinfo(FCAcurrentPath( t)) ; 

410  tiiStruct  startLevel  IS  STRUCT(cl . nd , cl . da , cl . owner , 

411  SENseidNsp(deslredGroup) , 

412  cl.priv): 

413 

414  EXCEPTIONS 

415  badt:  TPDB(t)  =?; 

416  noPath:  q  =  ?  AND  r  =  ?: 

417  badLevel:  NOT  LE (GADB(SENseidNsp(deslredGroup) ) .maxLevel, ndLevel ) ; 

418  badGroup:  GADB(SENseidNsp(desiredGroup))  =  ?; 

419  badPassWord:  pwdDesiredGroup  ~= 

420  GADB(SENseldNsp(deslredGroup) ) .password; 

421 

422  EFFECTS 

423  'TTIinfo(pSeid)  =  startLevel; 

424  IF  q~=  ?  THEN 

425  'FCAcurrentPath(t)  =  q 

426  ELSE 

427  'TIIinfo(r)  =  startLevel  AND 

428  'Tllinf o(UAADB( terminal User ( t )) • initial Process )  =*  startLevel  AND 

429  'FCAcurrentPath( t )  =  r  ; 

430  'auditTrailO  =*  VECTOR  (FOR  i  FROM  1  TO  LENGTH(auditTrail())+l : 

431  IF  i  <=  LENGTH  (auditTrailO)  THEN  auditTrailO  [  i  ] 

432  ELSE  "change  group"  ); 

433 

434 

435  OFUN  fileAccessModifier(seid  terminalGroup ,  fSeid;  nonDlsType  desirednd; 

436  modeStruct  da); 

437 

438  DEFINITIONS 

439  seid  t  IS  terminalGroup; 

440  tiiStruct  ftii  IS  Tllinfo(fSeid); 

441 

442  EXCEPTIONS 

443  badt:  TPDB(t)  =  ?; 

444  badFile:  Tllinfo(fSeid)  *  ?: 

445  badOwner :  ftii. owner  ~m  char sToInt ( terminalUser ( t ) ) ; 

446  $(User  must  own  file  he  is  trving  to  modify) 

447  badFileLevel :  ftii.nd 

448  minimurr  ,  i 
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449  ftli.nd, 

450  TPDB( t) .maxLevel , 

451  3DB( ) .maxLevel , 

452  UAADB( terminal User ( t ) ) .maxLevel , 

453  CADB(UAADB(terminalUser(t)) .initialLevel. group) .maxLevel 

454  }); 

455  badDeslredLevel :  desirednd 

456  minimum({ 

457  desirednd, 

458  TPDB( t ) .maxLevel , 

459  SDB( ) .maxLevel , 

460  UAADB( terminal User ( t ) ) .maxLevel , 

461  GADB(UAADB( terminal User ( t )). initialLevel . group) .maxLevel 

462  }); 

463 

464 

465  EFFECTS 

466  'TIIinfo(fSeid)  =  STRUCT(desirednd ,  da,  ftii. owner,  ftii. group, 

467  ftii.priv); 

468  'auditTrailO  =  VECTOR  (FOR  i  FROM  1  TO  LENGTH(auditTrail())+l: 

469  IF  1  <=  LENGTH ( audi t Trai 1( ) )  THEN  auditTrail () [ i ) 

470  ELSE  "file  fSeid  modified  to  desired  nd“  ); 

471 

472 

473  END  MODULE 
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1  MODULE  ale  $(access  level  control) 

2  $(" 

3  COPYRIGHT:  1978,  by  Ford  Aerospace  and  Communications  Corp. 

4  ADDRESS:  Ford  Aerospace  and  Communications  Corp. 

5  Western  Development  Laboratories 

6  3939  Fabian  Way 

7  Palo  Alto,  California  94303 

8  Attention:  Software  Technology  Dept. 

9  Mail  Stop:  V02 
10 

11  CPCI :  NKSR 

12  CPC: 

13 

14  MODULE  NAME:  ale  access  level  control 

15  FUNCTION: 

16  ASSUMPTIONS' 

17  HISTORY: 

18  AUTHOR:  Tom  Berson 

19  VERSION:  1.1  of  10/18/78 

20  MODULE  TYPE:  SPECIAL  Specifications 

21  SPECIAL  NOTES: 

22  ") 

23 

24 

25  TYPES 

26 

27  accessLevel :  STRUCT_0F( INTEGER  securityLevel , integrityLevel ; 

28  SET_0F  securityCat  sCatSet); 

29 

30  PARAMETERS 

31 

32  accessLevel  ALCgroundLevel ;  $ (level  for  terminals  not  logged  in) 

33  accessLevel  ALCloginLevel ;  $(initial  level  for  all  logins) 

34 

35 

36  EXTERNALREFS 

37 

38  FROM  smx : 

39  securityCat:  DESIGNATOR: 

40  integrityCat:  DESIGNATOR; 

41 

42 

43  FUNCTIONS 

44 

45  VFUN  ALCsetPermissible(accessLevel  p,max)->B00LEAN  B; 

46 

47  DERIVATION 

48  ( p .  securityLevel<armax .  securityLevel ) 

49  AND  (p. sCatSet  SUBSET  max. sCatSet) 

50  AND  (p .  integrityLevel<“max. integrityLevel ) ; 

51 

52 

53  END  MODULE 
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1  $("  MODULE:  despooler . spec s  (Version  1.9,  14:13:09) 

2  Module  Name  (dsp. specs) 

3  File  Name  (/kr/sunix/spec s/nksr/s .dsp . specs) 

4  CONTENTS  despooler  operations 

5  TYPE:  SPECIAL  specifications 

6  LAST  CHANGED:  11/21/80,14:13:09 

7 

8  -) 

9 

10  MODULE  despooler 

11 

12  $(''The  main  purpose  of  the  despooler  is  to  periodically  check 

13  if  files  are  spooled  for  printing,  and  if  so,  queue 

14  them  to  be  printed  one  at  a  time.  One  main  interface  is  thus 

15  to  the  spooler  mechanism,  which  indicates  the  currently  spooled 

16  files  in  the  VFUN  spooledFiles .  The  spooler  mechanism  puts  files 

17  from  the  "outside  world"  into  spooledFiles  via  the  OFUN  spool. 

18 

19  The  other  main  interface  of  the  despooler  is  to  the  "operator", 

20  i.e.,  someone  who  sends  the  following  sorts  of  commands  to  the 

21  despooler:  start,  stop,  die,  setLevel.  Start,  stop,  and  die 

22  force  the  despooler  to  look  like  a  state  transition  machine,  in  that 

23  printing  of  files  can  only  occur  from  state  started.  The  command 

24  setLevel  does  not  affect  the  state  transition  aspects,  but  merely 

25  changes  the  set  of  files  that  will  actually  be  printed. 

26  Also,  the  command  start  can  optionally  specify  a  new  level  at  which 

27  the  despooler  will  be  started.  In  these  specs,  the  new  level  will 

28  always  be  given  as  a  parameter  of  start.  The  level 

29  of  each  file  to  be  printed  must  be  <“  maxPrintLevel ,  which  Is  a  VFUN 

30  modified  as  a  result  of  interpreting  the  command  setLevel  or  start.  For  each 

31  of  the  four  commands,  the  operator  also  sends  an  indication  of  whether 

32  the  command  should  be  interpreted  "immediately”  or  after  the  currently 

33  queued  files  are  all  printed. 

34 

35  In  addition  to  the  "applicat lons-or iented"  tasks  of  queueing  and 

36  printing  files,  the  interrupt-handling  aspects  of  the  operator  commands 

37  must  also  be  indicated  in  these  specs. 

38 

39  As  a  way  of  structuring  these  specs,  the  following  six  categories 

40  of  objects  are  useful: 

41 

42  I.  Operator  Commands  -  setLevel,  start,  stop,  die. 

43  II.  Interrupt  Buffers  -  Boolean  VFUNS  which  are  initially  FALSE; 

44  they  are  set  to  TRUE  by  OFUN  issueCommand ,  and  reset  to  FALSE 

45  when  the  interrupt  is  actually  processed  by  OFUN  process  Interrupts . 

46  The  Boolean  VFUNS  are:  levbuf ,  startbuf,  stopbuf,  and  diebuf , 

47  corresponding  respectively  to  the  four  operator  commands  above. 

48  In  addition,  there  is  the  buffer  newLevbuf ,  indicating  the  new  level 

49  for  a  setLevel  or  start  command. 

50  III.  ILPL  events.  Below  are  given  abstract  programs  in  TLPL  for 

51  the  spooler,  despooler,  and  operator.  One  of  the  structuring 

52  mechanisms  of  ILPL  is  based  on  Zahn's  "event-indicator"  construct 

53  (see  Knuth's  "Str.  Pgmg  with  Gotos”  article). 

54  The  ILPL  events  used  in  the  programs  below  are: 

55  startE, stopE.dieE,  immlnt  ("immediate  interrupt"  ),  Qempty. 

56  IV.  BOOLEAN  VFUNS  corresponding  to  the  ILPL  events. 
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57 

58 

59 

60 
61 
62 

63 

64 

65  V. 

66 

67 

68 

69  VI. 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 
81 
82 

83 

84 

85 

86  OFUNS : 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

98 

99  The  ILPL  program  for  the  despooler  is  given  next. 

100 

101  (cycle  until  a  start  command  is  received.  This  also  sets  maxPrintLevel . ) 

102  UNTIL  dieE  DO 

103  UNTIL  stopE.dieE  DO 

104  processlnterrupts ; 

105  IF  VstopE  THEN 

106  OstopE; 

107  SIGNAL(stopE); 

108  END_IF 

109  IF  VdieE  THEN 

110  OdieE; 

111  SIGNAL(dieE); 

112  END  IF 


VstartE ,  VstopE,  VdieE.  Initially  FALSE;  tested  by  the  ILPL 
programs  to  determine  if  the  corresponding  events  should  be 
signalled.  Set  to  TRUE  by  OFUN  processlnterrupts.  Reset 
to  FALSE  by  OFUNS  given  in  the  next  category,  which  are  invoked 
by  the  ILPL  program  prior  to  signalling  the  event. 

(No  specific  VFUNS  are  needed  for  Qempty,  which  gets  signalled 
when  LENGTH(queue)  "  0;  or  for  immlnt,  which  gets  signalled 
when  nowbuf  is  TRUE. 

OFUNS  to  reset  the  BOOLEAN  VFUNS  in  category  IV  to  FALSE: 
OstartE,  OstopE,  OdieE. 

These  OFUNS  are  invoked  by  the  ILPL  program,  and  reset  the 
corresponding  VFUNS  to  FALSE. 

OFUNS  and  VFUNS  appropriate  to  spooler/despooler  functionality. 
The  following  are  the  major  ones: 

VFUNS:  spooledFiles  -  spooler  puts  files  here;  despooler 

takes  files  from  here  and  puts  them  on  queue, 
queue  -  files  wait  here  until  they  are  printed. 

If  a  setlevel  interrupt  occurs,  the  queue  may 
be  cleared  prior  to  printing  the  files.  The 
files  are  still  in  spooledFiles. 
output  -  simulates  line  printer  output.  New  printed 
pages  are  added  to  the  right  of  this  vector. 
maxPrintLevel  -  changed  by  setlevel.  Only  files  <* 
to  this  level  may  be  moved  from  the  outside 
world  to  spooledFiles,  or  from  spooledFiles 
to  queue. 

currentState  -  handles  state  transitions;  used  mainly 
by  OFUN  processlnterrupts. 


issueCommand  -  receive  command  from  operator,  and  set 
interrupt  buffers  appropriately, 
processlnterrupts  -  check  the  interrupt  buffers 

and  take  appropriate  action.  Handle  state 
transitions. 

processQel*  lent  -  dequeue  and  print  the  file  at  the 
beginning  of  the  queue. 

fillQueue  -  move  files  from  spooleFiles  to  queue. 

spool  -  move  files  from  the  outside  world  to  spooledFiles. 
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113  fillQueue; 

114  UNTIL  Qempty,  immlnt  DO 

115  IF  LENCTH(queue)  -  0  THEN; 

116  SIGNAL(Qempty ) 

117  END_IF 

118  IF  nowbuf ( )  THEN; 

119  SIGNAL( immlnt): 

120  END  IF 

121  processQelement ; 

122  THEN 

123  ON  Qempty:  ; 

124  ON  insnlnt: 

125  processlnterrupts ; 

126  IF  VstopE  THEN 

127  OstopE: 

128  SIGNAL(stopE); 

129  END_IF 

130  IF  VdieE  THEN 

131  OdieE; 

132  SIGNAL(dieE) ; 

133  END_IF 

134  END 

135  THEN 

136  ON  dieE:  SIGNAL(dieE); 

137  ON  stopE: 

138  UNTIL  startE  DO 

139  processlnterrupts; 

140  IF  VstartEQ  THEN 

141  OstartE; 

142  SIGNAL(startE) ; 

143  END_I F ; 

144  THEN 

145  ON  startE: 

146  END: 

147  END; 

148  THEN 

149  ON  dieE;  "abort": 

150  END 

152  The  abstract  program  for  the  spooler  is: 

153 

154  UNTIL  doomsday  DO 

155  spool (cFile , tFile) : 

156  END; 

158  The  abstract  program  for  the  operator  is: 

159 

160  UNTIL  doomsday  DO 

161  issueCommand(comd) ; 

162  END; 

163 

164 

165  The  operator  is  "supposed"  to  issue  commands  in  accordance  with 

166  the  following  state  transition  diagram. 

167 

168  set  level  (level) 
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169 

170 

1  71 

| - 1 

1  V 

/V 

start  (level) 

172 

173 

174 

Istarted  (level)l 

1  stopped  1 

\ 

stop  * 

175 

\ 

* 

176 

\ 

* - *  j 

177 

V 

— 

-»|dead|  1 

178 

die 

* - *  j 

179 

180 

181 

182 

1  1 

| - >» 

(system  startup) 

183  processlnterrup ts  makes  sure  that  this  diagram  is  obeyed. 

184  - 

185 

186  ") 

187 

188 

189  TYPES 

190  $(from  smx) 

191  nonDisType:  STRUCT_0F( 

192  INTEGER  securityLevel;  SET  OF  securityCat  securityCatS ; 

193  INTEGER  integrityLevel;  SET_0F  integrityCat  integrityCatS) ; 

194  S( integrityCat  is  typically  the  null  set) 

195  daType :  SETOF  daMode; 

196  modeStruct:  STRUCTjOF (daType  ownerMode,  groupMode*,  allMode); 

197  tiiStruct:  STRUCT_OF(nonDisType  nd; 

198  modeStruct  da;  INTEGER  owner,  group;  SETOF  privType  priv); 

199  $ ( from  fca) 

200  globalData:  STRUCT_0F( INTEGER  linkCount ,  openCount,  timeLastMod;  seid  subtype; 

201  BOOLEAN  openAtCrash ) ; 

202  $(state  information  for  all  openable  objects) 

203 

204 

205  $(Types  for  despooler  are  given  next.) 

206  line:  {VECTOR_OF  CHAR  x  I  LENGTH (x)  <-  maxLineLength } ; 

207  pagelmage:  {VECT0R_0F  line  x|  LENGTH(x)  <«  maxPageLength } ; 

208  outStream:  VECT0R_0F  pagelmage; 

209  textlmage:  VECT0R_0F  line; 

210  $(variables  of  type  textlmage  will  be  text  files  containing 

211  an  unbounded  but  finite  sequence  of  lines.) 

212  commands:  {setLevel , stop ,die , star t } ; 

213  $(The  commands  are  IPC  messages  that  can  be  received  by 

214  the  despooler.) 

215  dspStates:  {star ted , stopped, dead } ; 

216  marMsgTypc  :{VECT0R_0F  line  x  I  LENGTH(x)  *  marginHeadingLength } ; 

217  $(type  of  the  security  message  that  appears  at  top  and  bottom  of 

218  each  output  page.) 

219 

220  PARAMETERS 

221 

222  INTEGER  maxPageLength  $(Number  of  physical  lines  on  a  physical  page)  ; 

223  INTEGER  maxLineLength; 

224  INTEGER  marginHeadingLength;  $(Number  of  lines  in  top  margin  heading 
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225  that  appears  on  each  output  page;  this  same  number 

226  of  lines  also  appears  at  the  bottom  margin  of 

227  each  output  page.) 

228  marMsgType  margin.Msg(seid  cFile); 

229  $(Message  appearing  at  top  and  bottom  of  each  printed 

230  physical  page,  giving  owner,  security  level,  etc.) 

231  nonDisType  nullLevel;  $(when  die,  set  maxPrintLevel  to  nullLevel) 

232  VECTCROF  seid  emptyQueue;  $(Set  queue  to  emptyQueue  when  level  changes) 
23  3 

234  DEFINITIONS 

235 

236  INTEGER  maxNoTextLines  IS 

237  maxPageLeng th  -  2*marginHeadingLength ; 

238  $(max  number  of  usable  lines  per  output  page.) 

239  S(margin  message  aopears  at  top  and  bottom  of  page.) 

240 

241  INTEGER  numPages ( text  Image  file)  IS 

242  LENGTK(f il e) /maxNoTextLines  + 


243  (IF  LENGTH( file)  MOD  maxNoTextLines  =0  THEN  0  ELSE  1); 

244  S(Tells  how  many  output  pages  a  file  will  need  to  be  printed.) 

245 

246  pagelmage  bannerPage( line  msg)  IS 

247  VECTOR (FOR  i  FROM  1  TO  maxPageLength : 

248  IF  i  <=  marginHeadingLength  THEN 

249  marginMsg [ i ] 

250  ELSE  IF  i  =  marginHeadingLength  +  1  THEN 

251  msg 

252  ELSE  IF  i  INSET  {marginHeadingLength+2  ..  maxPageLength 

253  -  marginHeadingLength  }  THEN 

254  "  " 

255  ELSE  marginMsg[i  -  maxPageLength  +  marginHeadingLength] 

256  $(Put  margin  message  at  bottom  of  page.) 

257  ) 

258  ; 

259 

260  seid  seidAssoc(nonDisType  x)  IS 


261 

SOME  seid  yl  TIIinfo(y ) . nd  »  x; 

$(need 

a  seid,  rather  than  nonDisType, 

262 

to  pass 

as  a  parameter  to  SMXflow.) 

263 

, 

264 

EXTERNALREFS 

265 

266 

FROM  smx : 

267  INTEGER  SENlowLevel; 

268  INTEGER  SENhighLevel ; 

269  seid:  DESIGNATOR; 


270 

271 

272 

273 
2  74 

275 

276 

277 

278 

279 

280 


secureEntityType ;  {tFile,  tDevice ,  tTerminal,  tProcess,  tSegment,  tSubtype , 
tExtent,  tNullj: 


privType:  { 

privFileUpdateStatus , 
privModifyPriv, 
privSetFileLevel , 
privStickySeg, 
privViolSimpSecurity, 
privViolSimpIntegrity , 
privVIolDiscrAccess , 
privHalt, 


privLink,  privLockSeg, 

privMount , 

pr ivSetSegProcLevel , 
privTerminalLock, 
privViolStarSecurity, 
pr  IvViolStarlntegrity , 
privSignal,  privWalkPTable , 

privKernelCall ,  privViolCompartments , 
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281  privRealizeExecPermissions} ; 

282 

283  daMode:  {daRead,  daWrite,  daExecute}; 

284  securityCat:  DESIGNATOR; 

285  integrityCat :  DESIGNATOR; 

286  domainType:  {userDomain,  supervisorDomain} ; 

287 

288  VFUN  TIIinfo(seid  s)  ->  tilStruct  st; 

289  VFUN  SMXflow(seid  pSeid,  oSeld;  daType  da)  ->  BOOLEAN  b;  $(SMXflow) 

290  VFUN  SMXdap( seid  pSeid,  oSeld;  daType  da)  ->  BOOLEAN  b; 

291  VFUN  SENseidNsp( seid  anySeid)  ->  INTEGER  nsp; 

292  VFUN  SENseidTo Int( seid  anySeid)  ->  INTEGER  i; 

293  VFUN  SENseidType (seid  s)  ->  secureEntityType  set;  $(SENseidType) 

294  VFUN  SMXhasPri v(seid  pSeid;  privType  privl)  ->  BOOLEAN  b;  S(SMXhasPriv) 

2  95 

296  FROM  fca: 

297  VFUN  FCAinfo(seid  fSeid)  ->  globalData  gl;  $(FCAinfo) 

298 

299  FUNCTIONS 

300 

301  VFUN  spooledFiles()  ->  SET_OF  seid  controlFiles; 

302  ^(Assumed  to  be  set  by  spooler;  for  simplicity  in  specs, 

303  will  only  contain  control  files,  rather  than  <control  file, 

304  text  flle>  pairs.  A  separate  VFUN,  cToTfile,  will  give  the 

305  text  file  corresponding  to  any  control  file  in  spooledFiles . ) 

306 

307  HIDDEN; 

308  INITIALLY  controlFiles  -  {}; 

309 

310  VFUN  cToTfile(seid  controlFile)  ->  seid  textFile; 

311  $ (Assumed  to  be  set  by  spooler;  contains  the  text  file  associated 

312  with  a  given  control  file,  which  is  represented  in  the  implementation 

313  as  a  set  of  <control  file,  text  file>  pairs.) 

314 

315  HIDDEN; 

316  INITIALLY  textFile  «  ?; 

317 

318  VFUN  copies(seid  cFile)  ->  INTEGER  x; 

319  $(Assumed  set  by  spooler.  Gets  control  file  info;  specifically, 

320  how  many  copies  of  the  file  to  print.) 

321 

322  HIDDEN; 

323  INITIALLY  x  =?; 

324 

325  VFUN  textOf Seid(seid  x)  ->  textlmage  y; 

326 

327  HIDDEN; 

328  INITIALLY  y  -  ?; 

329  S(Assumed  set  by  spooler.) 

330  $(An  abstraction  away  from  the  representation  via  the  directory  structure.) 

331 

332  VFUN  currentState( )  ->  dspStates  x; 

333 

334  HIDDEN; 

335  INITIALLY  x  *  stopped;  $(Requires  an  interrupt  to  get  started.) 

336 
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337  VFUN  queue ( )  ->  VECT0R_0F  seid  qe ; 

338  $(0ne  of  the  main  VFUNS  in  despooler.  Files  are  copied  from 

339  spooledFiles  to  queue  by  the  OFUN  fillQueue.  From  queue,  the 

340  files  are  printed  one  at  a  time.  Files  remain  on  both  spooledFiles  and 

341  queue  until  the  files  are  printed,  or  determined  to  be  unprintable. 

342  When  printed,  they  are  removed  from  both  spooledFiles  and  queue. 

343  ) 

344 

345  INITIALLY  qe  =?; 

3  46 

347 

348  VFUN  maxPrintLevel()  ->  nonDisType  x; 

349  $("Only  files  at  or  below  maxPrintLevel  may  be  printed.  This  level 

350  is  set,  in  the  implementation,  at  the  beginning  of  the  despooler  code. 

351  It  is  set  in  these  specs  via  the  OFUN  initPrLevel. 

352  It  may  be  changed  via  the  IPC  command  setLevel.”) 

353 

354  $("In  the  implementation,  there  are  two  separate  “filters" 

355  appropriate  in  file  movement,  active .maxLevel  is  an  upper  bound 

356  on  security  level  for  files  moving  from  the  outside  world  to  spooledFiles, 

357  and  maxPrintLevel  is  an  upper  bound  on  files  moving  from  spooledFiles 

358  to  queue.  In  the  specs,  for  simplicity,  the  same  filter,  maxPrintLevel, 

359  is  used  in  both  circumstances.") 

360 

361 

362 

383  HIDDEN; 

364  INITIALLY  x«?; 

365 

366 

367  VFUN  outputO  ->  outStream  x; 

368  $(output  is  a  write-only  VFUN  simulating  actual  page  printing 

369  by  appending  new  pages  to  the  right  end  of  of  the  output  vector.) 

370 

371 

372  INITIALLY  LENGTH (x)  -  0; 

373 

374  $(The  following  VFUNS  are  the  interrupt  buffers.) 

375 

376  VFUN  nowbuf ( )  ->  BOOLEAN  x; 

377  INITIALLY  x  -  FALSE; 

378 

379  VFUN  levbuf ( )  ->  BOOLEAN  x; 

380  HIDDEN: 

381  INITIALLY  x  -  FALSE; 

382 

383  VFUN  startbuf ()  ->  BOOLEAN  x; 

384  HIDDEN; 

385  INITIALLY  x  *  FALSE; 

386 

387  VFUN  stopbuf C)  ->  BOOLEAN  x; 

388  HIDDEN; 

389  INITIALLY  x  -  FALSE; 

390 

391  VFUN  diebuf ()  ->  BOOLEAN  x; 

392  HIDDEN: 
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393  INITIALLY  x  -  FALSE; 

394 

395  VFUN  newLevbuf()  ->  nonDisType  x; 

396  HIDDEN; 

397  INITIALLY  x  =  ?; 

398 

399  $(The  following  VFUNS  correspond  to  ILPL  events.) 

400 

401  VFUN  VstartEO  ->  BOOLEAN  x; 

402  INITIALLY  x  =  FALSE; 

403 

404  VFUN  VstopEQ  ->  BOOLEAN  x; 

405  INITIALLY  x  =  FALSE; 

406 

407  VFUN  VdieEO  ->  BOOLEAN  x; 


408  INITIALLY  x  =  FALSE; 

409 

410 

412 

413  OFUN  processInterrupts( ) ; 

414  $( "Check  interrupt  buffers  and  take  appropriate  action.  Interrupts 

415  must  be  in  accordance  with  above  state  transition  diagram.”) 

416 

417  EXCEPTIONS 

418  badTrans  1 :  currentStateO  =  started  AND  startbufQ; 

419  badTrans2:  currentStateO  ■  dead; 

420  badTrans3:  currentStateO  m  stopped  AND 

421  (stopbufO  OR  diebufC)  OR  levbuf()); 

422  $(The  above  exceptions  rule  out  illegal  commands  from  each  state. 

423  Handling  of  multiple  legal  interrupts  from  state  started  is  as 

424  follows.  Set  level  and  stop  occuring  as  multiple  interrupts 

425  effectively  stop  the  abstract  machine  at  the  new  level.  Set  level 

426  and  die,  but  not  stop,  occuring  as  multiple  interrupts  essentially 

427  die  at  the  null  level,  with  the  queue  cleared.  Stop  and  die 

428  occuring  as  multiple  interrupts  effectively  treat  the  interrupts 

429  sequentially,  first  processing  the  stop.  Set  level,  stop,  and 

430  die  occuring  together  effectively  group  set  level  and  stop 

431  together  as  described  above,  and  then  sequentially  handle  the 

432  die.  "Sequentially”  is  used  here  wrt  consecutive  calls 

433  of  processlnterrupts  at  the  ILPL  level. 

434 

435  This  treatment  of  interrupts  is  an  abstraction  and  simplification 

436  vis-a-vis  the  implementation,  which  queues  the  interrupts  on  the 

437  same  queue  that  files  reside,  but  is  logically  equivalent  to  the 

438  implementation. 

439  ) 

440 

441 

442  EFFECTS 

443  IF  levbufQ  AND  stopbufO  THEN 

444  'outputO  -  VECTOR (FOR  I  FROM  1  TO  LENGTH (output ())+l: 

445  IF  i  <»  LENGTH  (outputO)  THEN  outputO  [i] 

446  ELSE  bannerPage( "new  level  and  stop"))  AND 

447  'levbufO  ■  FALSE  AND 

448  'currentStateO  »  stopped  AND 
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449 

450 

451 

452 

453 

454 

455 

456 

457 

458 

459 

460 

461 

462 

463 

464 

465 

466 

467 

468 

469 

470 

471 

472 

473 

474 

475 

476 

477 

478 

479 

480 

481 

482 

483 

484 

485 

486 

487 

488 

489 

490 

491 

492 

493 

494 

495 

496 

497 

498 

499 

500 

501 

502 

503 

504 


'maxPrintLevelQ  •  newLevbufQ  AND 
'queue ()  *  emptyQueue  AND 
'VstopEQ  *  TRUE  AND 
'stopbuf ()  *  FALSE 

ELSE  IF  levbuf ( )  AND  diebuf()  THEN 

'outputO  =  VECT0R( FOR  1  FROM  1  TO  LENGTH (output ( ))+l: 

IF  i  <=  LENGTH(outputO)  THEN  output()[i] 

ELSE  bannerPage( "new  level  and  die”))  AND 
'levbuf ()  -  FALSE  AND 
'currentState ( )  =*  dead  AND 
'maxPrintLevelQ  =  nullLevel  AND 
' queue ()  =  emptyQueue  AND 
'VdieEQ  =  TRUE  AND 
'diebuf ( )  -  FALSE 

ELSE  IF  levbuf ( )  THEN 

'maxPrintLevel(  )  =  newLevbufQ  AND 

'output ()  »  VECT0R(F0R  1  FROM  1  TO  LENGTH (output () )+l : 
IF  i  <»  LENGTH (outputQ)  THEN  output()[i] 

ELSE  bannerPage( "new  level") 

)  AND 

' levbuf ()  -  FALSE  AND 
'queue ()  =  emptyQueue 

ELSE  IF  stopbuf ( )  THEN 

'currentState ( )  »  stopped  AND 
'VstopEQ  =  TRUE  AND 
'stopbuf ()  *  FALSE  AND 

'outputQ  -  VECTOR (FOR  i  FROM  1  TO  LENGTH (ouCpu t( ))+l : 
IF  1  O  LENGTH  (outputQ)  THEN  output()[iJ 
ELSE  bannerPage( "stopped") 

) 

ELSE  IF  diebufQ  THEN 

'currentState ( )  *  dead  AND 
'maxPrintLevelQ  *  nullLevel  AND 
'VdieEQ  *  TRUE  AND 
'diebufQ  =*  FALSE  AND 

'outputQ  -  VECT0R(F0R  i  FROM  1  TO  LENGTH  (output  ()  )+l : 
IF  i  O  LENGTH( outputQ)  THEN  outputQ  [i] 

ELSE  bannerPage("dead") 

) 

ELSE  IF  startbuf ()  THEN 

'currentState( )  ■  started  AND 
'maxPrintLevelQ  =*  newLevbufQ  AND 
' queue ()  =  emptyQueue  AND 
'VstartEQ  -  TRUE  AND 
'startbufQ  “  FALSE  AND 

'outputQ  -  VECTOR (FOR  i  FROM  1  TO  LENGTH (output () )+l : 
IF  i  O  LENGTH(outputQ)  THEN  outputQ  [i] 

ELSE  bannerPage("started" ) 

) 

ELSE  TRUE 
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505 

506 

507  OFUN  issueCommand(commands  cmd;  nonDisType  level;  BOOLEAN  1mm); 

508  $(Set  the  appropriate  interrupt  buffers  based  on  the  command.) 

509 

510  $(****Put  in  exception  check  that  issueCommand  is  invoked  by 

511  someone  at  or  above  operator  integrity.) 

512 

513 

514  EFFECTS 

515  IF  cmd  =  setLevel  THEN 

516  'levbuf ( )  =  TRUE  AND 

517  'newLevbufO  =  level 

518  ELSE  IF  cmd  =  start  THEN 

519  'star  tbuf  ( )  =*  TRUE  AND 

520  'newLevbufO  =  level 

521  ELSE  IF  cmd  =  stop  THEN 

522  'stopbuf ( )  =  TRUE 

523  ELSE  IF  cmd  =  die  THEN 

524  'diebuf ( )  =  TRUE 

525  ELSE 

526  TRUE; 

527 

528  IF  innn  THEN 

529  'nowbuf ( )  -  TRUE 

530  ELSE 

531  TRUE; 

532 

533  OFUN  spool(seid  cFile, tFile:  INTEGER  ncopies:  textlmage  text); 

534  $(Move  the  file  from  the  "outsia,.  ’orld"  to  spooledFiles .  File 

535  must  be  at  or  below  maxPrintLevel .  In  the  implementation, 

536  active. maxLevel  is  used  instead  of  maxPrintLevel  in  moving  files 

537  to  spooledFiles,  and  maxPrintLevel  is  used  in  moving  files  from 

538  spooledFiles  to  queue.  For  simplicity  in  these  specs,  the  same 

539  discriminator,  namely  maxPrintLevel,  is  used  for  both.) 

540 

541  EXCEPTIONS 

542  badLevel:  NOT  SMXflow(cFile ,  seidAssoc(maxPrintLevel()) ,  {daWrite}); 

543 

544  EFFECTS 

545  'spooledFilesO  =  spooledFiles()  UNION  {cFile}; 

546  'cToTfile(cFile)  -  tFile; 

547  'copies(cFile)  -  ncopies; 

548  'textOfSeid( tFile)  “  text; 

549 

550 

551  OFUN  fillQueueO; 

552  $("Copy  files  from  spooledFiles  to  queue,  without  currently  removing 

553  them  from  spooledFiles.  Only  files  whose  current  level  is  less 

554  than  or  equal  maxPrintLevel  are  copied.  ") 

555 

556  DEFINITIONS 

557 

558  SET_0F  seid  queueableFiles  IS  {seid  x  I  x  INSET  spooledFilesO  AND 

559  $(1.  Not  in  queue)  (F0RALL  INTEGER  j  INSET  {1  ..  LENGTH (queue ( ) ) }  : 

560  queue()[j]  x) 
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561  AND  $(2.  )  SMXflow(x,  seidAssoc(maxPrintLevel() ) ,  {daWrite}) 

562  } 

563  ;  $(queueableFiles  is  the  set  of  files  about  to  move  onto  queue) 

564 

565  VECT0R_0F  seid  setToVec(SET_0F  seid  x)  IS 

566  SOME  VECTOR  OF  seid  y  |  LENGTH (y)  =  CARDINALITY( x) 

567  AND  (FORALL  INTEGER  i  INSET  {1  ..  CARDINALITY(x) } : 

568  y [ i ]  INSET  x) 

569  AND  (FORALL  seid  j  INSET  x:  EXISTS  INTEGER  k  INSET 

570  {1  ..  CARDINALITY  (x)}:  j  =  y[k]) 

571  ;  $(setToVec  merely  "linearizes"  a  set  into  some  arbitrary  order. 

572  In  the  implementation,  the  order  in  which  files  are  queued 

573  is  based  partly  on  file  length.  In  these  specs,  the  order  is  arb. ) 

574 

575 

576  EXCEPTIONS 

577 

578  XnoObj:  EXISTS  seid  x  INSET  spooledFiles( ) : 

579  TIIinfo(cToTfile(x))  =?; 

580  XnoFile:  EXISTS  seid  x  INSET  spoo ledFiles (  ) : 

581  FCAinfo(cToTfile(x))  =?; 

582 

583 

584  ASSERTIONS 

585  LENGTH (queue())  =  0; 

586  $("  Whenever  fillQueue  is  invoked  the  queue  is  empty  because. 

51 7  queue  starts  out  empty;  after  queue  is  filled  by  fillQueue, 

588  each  element  on  the  queue  is  processed  prior  to  fillQueue  being 

589  reinvoked,  or  else  an  interrupt  occurs  forcing  queue  to  be  cleared 

590  prior  to  fillQueue  being  re  invoked ." ) 

591 

592 

593  EFFECTS 

594 

595  'queueO  =>  VECT0R(F0R  i  FROM  1  TO  CARDINALITY(queueableFiles)  : 

596  setToVec(queueableFiles) [ i] )  ; 

597 

598  • 

599  0FUN  processQelement( ) ; 

600  S(dequeue  the  first  element  of  queue  and  print  associated  file.) 

601 

602  DEFINITIONS 

603  seid  cFileSeid  IS  queue()[l]; 

604  textlmage  text  IS  textOf Seid(cToTfile(cFileSeid)) ; 

605  INTEGER  curLength  IS  numPages ( text )  +  2;  $(2  extra:  banner  &  trailer) 

606 

607  EXCEPTIONS 

608  emptyQ:  LENGTH(queue( ) )  *  0; 

609 

610  EFFECTS 

611  'outputO  -  VECTOR  (FOR  i  FROM  1  TO  LENGTH(output  ( ) )  + 

612  co pies (cFileSeid )*(numPages( text)+2 ) : 

613  $(banner  +  trailer  page 

614  for  each  copy  of  the  file) 

615  IF  i  <-  LENGTH ( out  put ( ) )  THEN  output()|i] 

616  ELSE  IF  (1  -  LENGTH (output () ))  MOD  curLength  INSET  {0,1}  THEN 
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617  bannerPage( "normal  file") 

618  ELSE  IF  (1  -  LENGTH (output ()) )  MOD  curLength  *  curLength  -1  THEN 

619  $(last  page  of  text  may  not  be  full) 

620  VECT0R(F0R  j  FROM  1  TO  LENGTH( text)  MOD  maxNoTextLlnes : 

621  text (LENGTH (text)  -  (LENGTH (text)  MOD  maxNoTextLlnes)  +j] 

622  $(****Does  not  yet  account  for  top  and  bottom  margin) 

623  ) 

624  ELSE 

625  VtCTOR (FOR  j  FROM  1  TO  maxNoTextLlnes: 

626  text[  (( ( i-LENGTH(output ( )  ))  MOD  curLength)  -  2) 

627  *  maxNoTextLlnes  +  j]) 

628  $(****Does  not  yet  account  for  to~  and  bottom  margin) 

629  )  $  ( "end  of  'outputQ  =  VECTOR...") 

630  AND 

631  'spoo ledFlles( )  =  spooledFiles( )  DIFF  {cFileSeid} 

632  AND 

633  'cToTf ile(cFile)  =  ? 

634  AND 

635  'copies(cFile)  =  ? 

636  AND 

637  textOfSeid (cToTf ile(cFile)  )  =  ? 

638 

639 

640 

641  $(The  following  OFUNS  manipulate  the  VFUNS  corresponding  to  ILPL  events.) 

642 

643  OF  UN  OstartEQ; 

644  EFFECTS 

645  'VstartEO  =  FALSE; 

646 

647  OFUN  OstopE ( ) ; 

648  EFFECTS 

649  'VstopE ( )  =  FALSE; 

650 

651  OF'JN  OdieE(); 

652  EFFECTS 

653  'VdleEO  =  FALSE; 

654 

655 
6  56 

657  END  MODULE 
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$(password  encryption  serivce) 

$(password  encryption  serivce) 

1978,  by  Ford  Aerospace  and  Communications  Corp. 
Ford  Aerospace  and  Communications  Corp. 

Western  Development  Laboratories 
3939  Fabian  Way 
Palo  Alto,  California  94303 
Attention:  Software  Technology  Dept. 

Mail  Stop:  V02 

12  CPC I:  NKSR 

13  CPC: 

14  MODULE  NAME:  enc  password  encryption  service 

15  FUNCTION:  encryption  of  passwords 

16  ASSUMPTIONS:  that  the  Govt,  will  give  us  an  algorithm 

17  HISTORY: 

18  AUTHOR:  Tom  Berson 

19  VERSION:  1 . 1  of  10/18/78 

20  MODULE  TYPE:  SPECIAL  Specifications 

21  SPECIAL  NOTES: 

22  ") 

23 

24 

25  TYPES 

26 

27  password:  VECTOROF  CHAR  : 

28  encryptedPw:  {VECTOROF  CHAR  e I LENGTH(e)«ENCepw Length} ; 

29 

30 


1  MODULE  enc 

2  MODULE  enc 

3  $(" 

COPYRIGHT: 
ADDRESS: 


4 

5 

6 

7 

8 
9 

10 


31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 


PARAMETERS 

INTEGER  ENCepwLength; 

FUNCTIONS 

VFUN  ENCrypt (password  pw)->encryptedPw  epw: 

$(definition  of  the  insides  of  this  function  to  be  provided  by 
KS0S  customer) 

END  MODULE 
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1  MODULE  ffn  $(file  and  terminal  functions) 

2  MODULE  ffn  $(file  and  terminal  functions) 

3  $(" 

4  COPYRIGHT:  1978,  by  Ford  Aerospace  and  Communications  Corp. 

5  ADDRESS:  Ford  Aerospace  and  Communications  Corp. 

6  Western  Development  Laboratories 

7  3939  Fabian  Way 

8  Palo  Alto,  California  94303 

9  Attention:  Software  Technology  Dept. 

10  Mail  Stop:  V02 

11 

12  CPCI :  NKSR 

13  CPC: 

14  MODULE  NAME:  ffn  file  and  terminal  functions 

15  FUNCTION:  sets  the  terminal  level 

16  ASSUMPTIONS:  none 

17  HISTORY: 

18  AUTHOR:  Tom  Berson 

19  VERSION:  1.1  of  10/18/78 

20  MODULE  TYPE:  SPECIAL  Specifications 

21  SPECIAL  NOTES:  none 

22  ") 

23 

24 

25  TYPES 

26 

27  terld:  {0..255}; 

28  openDescriptor :  { 1 . . PSTmaxOpenDescriptor s} ; 

29  openModes:  {omStatusUpdate } ; 

30  accessLevel:  STRUCT_0F( INTEGER  sec- -ityLevel.integrityLevel; 

31  SETOF  securityCat  sCatSet); 

32  tiiStruct:  STRUCTjOF (INTEGER  securityLevel;  SETOF  securityCat  sCatSet; 

33  INTEGER  integrityLevel ;  SETOF  integrityCat  iCatSet ; 

34  INTEGER  da;  seid  owner .group); 

35 

36 

37  DECLARATIONS 

38 

39  openDescriptor  odx.ody; 

40 

41 

42  EXTERNALREFS 

43 

44  FROM  sen: 

45  seid:  DESIGNATOR; 

46 

47  FROM  smx: 

48  securityCat:  DESIGNATOR; 

49  integrityCat:  DESIGNATOR; 

50 

51  FROM  pst: 

52  INTEGER  PSTmaxOpenDescriptor s ; 

53 

54  FROM  ker : 

55  VFUN  K_get_object_level (INTEGER  od )->tiiStruct  level; 

56  OFUN  K  set  object  level (INTEGER  od;  tiiStruct  level); 
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57  OVFUN  K_open(seid  oSeid;  SET_0F  openModes  om; INTEGER  stCap) 

58  ->openDescriptor  od; 

59 

60  FROM  ale: 

61  VFUN  ALCsetPermlssible(accessLevel  proposed ,maximum)->B00LEAN  b ; 

62 

63  FROM  tdb : 

64  VFUN  TDBexists( terld  tid)->BOOLEAN  b; 

65  VFUN  TDBlocked( terld  tid)->B00LEAN  b; 

66  VFUN  TDBstandardSeld( terld  tid)->seid  s; 

67  VFUN  TDBsecure Seid (ter Id  tid)->seid  s; 

68  VFUN  TDBmaxLevel ( ter  Id  t)->accessLevel  al ; 

69 

70 

71  FUNCTIONS 

72 

73  OFUN  FFNsetTerminalLevel(terId  tld ; accessLevel  al; 

74  seld  newOwner,  newGroup;  INTEGER  newDa); 

75 

76  DEFINITIONS 

77  $(Note  that  in  these  definitions  odx  is  not  yet  bound->a  scope 

78  error.  However,  odx  is  bound  in  the  scope  where  the  definitions 

79  are  used.) 

80  seid  lowner  IS  IF  newOwner-?  THEN  K_get_objec t_level( odx ) .owner 

81  ELSE  newOwner; 

82  seid  lgroup  IS  IF  newGroup-?*  THEN  K_get_object_level(odx) .group 

83  ELSE  newGroup; 

84  INTEGER  Ida  IS  IF  newDa-?  THEN  Kgetob jectlevel(odx) .da 

85  ELSE  newDa; 

86 

87  EXCEPTIONS 

88  NEffnBadTerminal :  ~TDBexists( tid) ; 

89  NEffnTerminalLocked:  TDBlocked(tid); 

90  NEffnBadLevel:  “ALCse t Perm is sible(al, TDBmaxLevel (tid)) ; 

91 

92  EFFECTS 

93  LET  tiiStruct  newLevel-STRUCT(al . securi tyLevel , al . sCatSet , 

94  al . integrityLevel , ? , 

95  Ida, lowner , lgroup) 

96  $(set  the  level  of  the  standard  path) 

97  IN  LET  odx-EFFECTS_OF  K_open(TDBstandardSei 

98  {omStatusUpdaue; ,  . 

99  IN  EFFECTS  OF  K_se t_ob  ject_level  (odx  ,newLevtJ. ) 

100  $(also  set  the  level  of  the  secure  path) 

101  AND  (LET  ody-EFFECTS_OF  K_open(TDBsecureSeid ( tid ) , 

102  {omStatusUpdate} , ?) 

103  IN  EFFECTSjOF  K_set_ob ject_level(ody,newLevel) ) ; 

104 

105 

106  END  MODULE 
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MODULE  gdb 
MODULE  gdb 
$(" 

COPYRIGHT: 

ADDRESS: 


1 
2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12  CPCI :  NKSR 

13  CPC: 

14  MODULE  NAME 
FUNCTION: 


$(group  access  authentication  data  base) 
$(group  access  authentication  data  base) 

1978,  by  Ford  Aerospace  and  Communications  Corp. 
Ford  Aerospace  and  Communications  Corp. 

Western  Development  Laboratories 
3939  Fabian  Way 
Palo  Alto,  California  94303 
Attention:  Software  Technology  Dept. 

Mail  Stop:  V02 


15 

16 

17  ASSUMPTIONS: 

18  HISTORY: 


,’db  group  access  authentication  data 
ro'ip  access  authentication  data  base 


ba 


none 


19 

20 
21 
22 

23 

24 


AUTHOR:  Tom  Berson 

VERSION:  1.1  of  10/18/78 

MODULE  TYPE:  SPECIAL  Specifications 
SPECIAL  NOTES:  none 
") 


1 

25 

f. 

26 

TYPES 

1 

27 

28 

groupName:  : VECTOR  OF  CHAR  g ILENGTH (g)  >=  1 } : 

r 

29 

encryptedPw:  {VECTOROF  CHAR  elLENCTH(e)  -  EMCepwlength } ; 

i 

30 

userid: seid; 

31 

groupla:  seid; 

• 

32 

accessLevel:  STRUCT  OF(INTEGER  securityLevel , integrityLevel 

33 

SET  OF  securityCat  sCatSet); 

r 

34 

k 

35 

■ 

36 

PARAMETERS 

37 

L 

38 

encryptedPw  r.ullEpw: 

> 

39 

- 

40 

k 

E 

41 

EXTERNALREF3 

42 

j 

43 

FROM  sen: 

b  ' 

44 

seid:  DESIGNATOR; 

|  | 

45 

I' 

46 

FROM  tii: 

r  1 

47 

securityCat:  DESIGNATOR; 

48 

j 

49 

FROM  enc : 

50 

INTEGER  ENCepwLength ; 

51 

[  i 

52 

Mm 

ASSERTIONS 

am  j 

19 . 

F0RALL  groupName  x: 

56 

CARDINALITY({groupId  gid lGDBgroupNane( gld )  »  x})  '  *  1; 
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57  $(In  other  words,  we  require  unique  group  names.) 

58 

59 

60  FUNCTIONS 

61 

62  $( - group  access  control  info - ) 

63 

64  VFUN  GD8groupName(grouoId  gid )->groupName  gn; 

65 

66  INITIALLY  gn=?; 

67 
63 

69  VFUN  GDBencryptedPw(groupId  gid )->encryptedPw  e; 

70  $(group  passwords  are  optional) 

71 

72  INITIALLY  e-nullEpw; 

73 
'  *+ 

75  VFUN  GDBadministratori groupld  gid)->userld  admin; 

76  $(0nly  the  group  administrator  may  modify  his  group's  \  assword) 

77 

78  INITIALLY  admin-?; 

79 

80 

81  VFUN  GDBmaxLe vel(grouold  gid)->accessLevel  1: 

82 

83  INITIALLY  1-7; 

84 
35 

86  S( - db  extraction  functions - — - ) 

37 

88  VFUN  GDBvalidGroupName(groupName  gn)->B00LEAN  b; 

39 

90  DERIVATION 

91  EXISTS  groupld  2id  :  GDBgroupMame(gid)-gn ; 

92 

93 

94  VFUN  GDBgetGroupId(groupName  gn)->groupId  gid; 

95 

96  EXCEPTIONS 

97  NEgdbBadName •  “GDBva lidGroupName(gn) ; 

98 

99  DERIVATION 

100  SOME  groupld  x  I  GDBgroupName(x)-gn; 

101 

102  VFUN  GDBpwExists( groupld  gid)->B0OLEAN  b: 

103 

04  DERIVATION 

.05  N0T(GD8encryptedPw(gid)  -  nullEpw); 

106 
i  07 

108  END  MODULE 
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1  MODULE  pfn  $(process  functions) 

2  MODULE  pfn  $ (process  functions) 

3  $r 

4  COPYRIGHT:  ’.978,  by  Ford  Aerospace  and  Communications  Oorp. 

5  ADDRESS:  Ford  Aerospace  and  Communications  Corp. 

6  Western  Development  Laboratories 

7  3939  Fabian  Way 

8  Palo  Alto,  California  94303 

9  Attention:  Software  Technology  D:pt. 

10  Mail  Stop:  V02 

11 

12  CPC  I :  N'KSR 

13  CPC: 

14  MODULE  NAME:  pfn  process  functions 

15  FUNCTION:  process  functions: 

16  sett  in.:  process  level, 

17  get  tin,:  process  level, 

18  determination  of  whether  we  have  an  active  shell  at  level  L 

19 

20  ASSUMPTIONS :  none 

21  HISTORY: 


22 

AUTHOR:  To 

m  Berson 

23 

VERSION:  1. 

i  of  10/18/78 

24 

MODULE  TYPE: 

SPECIAL  Specifications 

25 

SPECIAL  NOTES: 

none 

26 

") 

27 

28 

29 

TYPES 

30 


31  userid:  seid: 

32  groupld:  seiu: 

33  terla :  il. .255}; 

34  accessLevel:  STRUCT0F (INTEGER  securltyLevel , integrityLevel: 

35  SET_0F  securityCat  sCatSet); 

36  tiiStruct: STRUCT_OF(INTEGER  securltyLevel : SET_0F  securityCat  sCatSet; 

37  INTEGER  integrityLevel ; SET __0F  integrityCat  ICatSet; 

38  INTEGER  da;  seid  owner , group) ; 

39  activeEntry:STRUCT_OF(terId  tld ; accessLevel  al:seid  pSeid); 

40 

41 

42  PARAMETERS 

43 

44  seid  PFNuserStarter ; 

45 


46 

47  EXTERNALREFS 

48 

49  FROM  sen: 

50  seid:  DESIGNATOR; 

51 

52  FROM  smx: 

53  securityCat:  DESIGNATOR; 

54  integrityCat:  DESIGNATOR; 

55 

56  FROM  ker: 
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57  VFUM  K_get_proct'SS_le'/el()->tiiSti.-uce  level: 

58  OFUN  K_set_procfcss_level(tllStruct  level); 

59  OVFUN  K_spawn(sc id  pSt>id;VECTOR  Of  CHAR  pl,p2)->seid  nevSeid: 

60 

61  FROM  udb : 

62  VFUN  UDBvalidUsor(userId  uid )->B00LEAN  b: 

63  VFUN  UDB  ini  till  Shell  (userid  uid )->VECT0R_0F  CHAR  s; 

64  VFUN  UDB  log  in  3i  rector  y(  user  Id  uid)->VECT0R  OF  CiiAR  d; 

65 
6o 

67  FUNCTIONS 

68 

69  $( -  process  level  manipulation  functions  - ) 

70 

.1  OF UN  PFNsetPrccessLevel (accessLevel  al;  seid  newOwner,  rjwGroup; 

INTEGER  newDa); 

73 

74  DEFINITIONS 

75  seid  lowner  IS  IF  newOwner*?  THEN  K  get  process  level()  owner 

76  ELSE  newOwner; 

77  seid  lgroup  IS  IF  newGroup*?  THEN  K  get  process  level!)  group 

78  ELSE  newGroup; 

79  INTEGER  Ida  IS  IF  newDa*?  THEN  K  get_process_level () .da 

80  ELSE  newDa; 

81 

82  EFFECTS 

33  LET  tiiStruct  old*K_get_process_level () 

84  IN  LET  tiiStruct  new«STRUCT( 

85  al.securityLevel.al .sCatSet , 

86  al .integrityLevel.old.lCatSet , 

87  Ida  ,  lowner , lgroup) 

38  IN  EFFECTS_OF  K  setprocesslevel(new) ; 

89 

90  VFUN  PFNgetProcessLevel ( )->STRUCT _OF(accessLevel  al ;  us -rid  owner. 

91  groupld  grout>)pal; 

92 

93  DERIVATION 

94  LET  tiiStruct  s*K_gec  process  level() 

95  IN  STRUCT(STRUCT(s . securit yLe vel , s . integri t vLevel , s .  ;CatSet ) , 

96  s  .owner ,s .group) ; 

97 

98 

99  $( - active  shell  level  memory - ) 

100 

101  VFUN  h_activeSat()->SET_OF  activeEntry  aes: 

102 

103  HIDDEN; 

’04  INITIALLY  aes*?; 

105 

106 

107  OFUN  PFMpostActive(activeEntry  a); 

108 

109  EXCEPTIONS 

110  NEpfnActiveAlready :  a  INSET  h  activeSetQ: 

111 

112  EFFECTS 
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113  'h_activeSet()»h_activeSet()  ’JNION  {a}; 

114 

115 

116  OFl’N  PFNstrikeAllActiveShellsC ter  Id  ptid); 

'17 

118  EFFECTS 

119  'h_activeSei ( ) =h_act iveSet( )  DIFF 

120  {activeEntry  aelae  INSET  h_ac tiveSet( ) 

121  AND  ae. tid-pt id} : 

.22 

123 


124  VFUN  PFNquer yAc cive( terld  ptid:  accessLevel  pal)->seld  .ctiveSeid; 

1  25 

126  DERIVATION 

127  IF  EXISTS  activeEntry  ae :  ae .  tid=pt  id  AND  ae.al*pal  AND  :*e  INSET  h  activeSet() 

128  THEN  ae.pSeid  $(not  legal  in  SPECIAL,  must  b«  rebound) 

129  ELSE?  ;  $(NB  the  ?  here  is  a  distinguished  r.  turn) 

130 

131 

132  S( - common  startup  function - 

133 

134  0FCN  PFllstar cl'ser(terld  tid;  userid  uid;  accessLevel  al  ; 

135 

136  EXCEPTIONS 

137  NEpfnBadUser  :  “UDBvalidUser (uid); 

138 

139  EFFECTS 

140  LET  seid  startedSeid  a  EFFECTS  OF  K_spawn(PFNuserStarter , 

141  UDBinitialShell(uid) .UDBloginDirectory(uid)) 
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1  MODULE  sdb  S 'system  data  base) 

2  MODULE  sdb  $(system  data  base) 

3  S(" 

4  COPYRIGHT:  1973,  by  Ford  Aerospace  and  Communications  Corp. 

5  ADDRESS:  Ford  Aerospace  and  Communications  Corp. 

6  Western  Development  Laboratories 

7  3939  Fabian  Way 

3  Palo  Alto,  California  94303 

9  Attention:  Software  Technology  Dept. 

10  Mail  Stop:  V02 

11 

12  CPCI :  NKSR 

13  CPC: 

14  MODULE  NAME:  sdb  system  data  base 

15  FUNCTION:  system  level  data  base 

16 

17  ASSUMPTION'S:  none 

18  HISTORY: 

19  AUTHOR:  Tom  Berson 

20  VERSION:  1.1  of  10/18/78 

21  MODULE  TYPE:  SPECIAL  Specifications 

22  SPECIAL  NOTES:  none 

23  ") 

24 

25 

26  TYPES 

27 

28  accessLevel-  STRUCT_0F( INTEGER  securityLevel , integrityL.  vel; 

29  SET0F  securityCat  sCatSet); 

30 

31 

32 

33  EXTERNALREFS 

34 

35  FROM  smx: 

36  securityCat:  DESIGNATOR; 

37 

38 

39  FUNCTIONS 

40 

41  VFUN  SDBmaxLevel()->accessLevel  1: 

42 

43  INITIALLY  1=*?; 

44 

45 

46  $(and  other  functions  required  to  support  operator  and  administrator 

47  control  functions.) 

48  END  MODULE 
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1  MODULE  tdb  $(terminal  data  base) 

2 

3  TYPES 

4 

5  terld : {0. . 255 } : 

6  accessLevel:  STRL'CT_OF( INTEGER  securityLevel , integrityLavel ; 

7  SET_OF  securltyCat  sCatSet): 

8 
9 

10  PARAMETERS 

11 

12  $(these  contribute  to  the  state  of  terminals  between  logout  and  login) 

13  INTEGER  TDBd^ faultDa ; 

14  seid  TDBdefa-1 tOwner , TDBdefaultGroup ; 

15 

16 

17  EXTERNALS EPS 

18 

19  FROM  sen: 

20  seid:  DESIGN '.TOR: 

21 

22  FROM  tii: 

23  securityCat:  DESIGNATOR; 

24 

25 

26  FUNCTIONS 

27 

28  $( - terminal  state  information - ) 

29 

30  VFUN  TDBexiscs(terId  tid )->BOOLEAN  b; 

31 

32  INITIALLY  b-FALSE; 

33 

34  $(  terminals  are  brought  into  existence,  i.e.  configured,  by  the 

35  use  of  the  system  configuration  editor.  They  arrive  3t  reboot.) 

36 

37 

38  VFUN  TDBlocked ( terld  tid )~>B0O LEAN  b; 

39 

40  INITIALLY  b»FALSE ; 

41 

4?  $(  Terminals  cannot  be  dynamically  removed  from  configuration. 

43  They  should  be  locked  by  the  operator,  and  TDBexists  then 

44  edited.  They  will  then  be  gone  at  reboot.  ) 

45 

46 

47  VFUN  TDBstandardSeid( terld  tid)->seid  stdSeid; 

48 

49  INITIALLY  stdSeid-?; 

50 

51 

52  VFUN  TDBsecureSeid(terId  tid)->seid  secSeid; 

53 

54  INITIALLY  secSeid-?; 

55 

56 
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57  VFUN  TDBmaxLevel (terld  tid)->accessLevel  1; 

58 

59  INITIALLY  1-7: 

60 

61  VFUN  TDBde faults pee d( ter Id  tid)->INTEGER  speed; 

62 

63  INITIALLY  speed-?; 

64 

65 

56  VFUN  TDBde fan ltKi 11 ( terld  tid)->CHAR  k; 

67 

68  INITIALLY  k-7; 

69 

70 

71  VFUN  TDBdefa-tltEraseC terld  tld)->CHAR  e: 

72 

73  INITIALLY  e-’; 

74 

75 

76  END  MODULE 
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1  MODULE  uac  $(user  access  control  functions) 

2  $(  all  functions  in  this  module  are  subfunctions  of  the 

3  secure  server,  which  is  responsible  for  dialog  with  the 

4  user  and  for  assembling  the  necessary  parameters.) 

5 

6  TYPES 

7 

3  userld:seid; 

9  groupld:  seid: 

10  ter Id : { 1 . .  255  } : 

11  userNarae:  {\T.CT0R_0F  CHAR  un  I  LEN'GTH(un)  >-  1}: 

12  groupName :  { VECTOR  _0F  CHAR  gn I  LENGTH (  gn )  >=  1 } ; 

13  accessLevel :  5TRUCT_0F( INTEGER  securityLevel . integr  ityL<- vel ; 

14  SET  OF  securityCat  sCatSet); 

15  password:  {VECTOROF  CHAR  nTLENGTH(n)>=l } ; 

16  encryptedPw:  {VECTORjOF  CHAR  e I  LENGTH (e)=EMCe pw Length } ; 

17 

18 

19  EXTERNALREFS 

20 

21  FROM  sen: 

22  seid:  DESIGNATOR; 

23 

24  FROM  tii: 

25  securityCat:  DESIGNATOR: 

26 

27  FROM  N_: 

28  OFUN  N_ki ll_al 1 ( sei d  terSeid): 

29 

30  FROM  ale: 

31  VFUN  ALCsetPermissible(accessLevel  p,max)->B00LEAN  b; 

32  accessLevel  ALCgroundLevel ; 

33  accessLevel  ALClogin Level; 

34 

35  FROM  enc  : 

36  VFUN  ENCrypt (password  p)->encryptedPw  epw; 

37  INTEGER  ENCepwLength : 

38 

39  FROM  sdb : 

40  VFUN  SDBmaxLevel()->accessLevel  mal; 

41 

42  FROM  tdb : 

43  userid  TDBdefaultOwner ; 

44  groupld  TDBdefaultGroup ; 

45  INTEGER  TDBdefaultDa ; 

TDBlocked ( ter Id  tid)->B00LEAN  b; 

TDBstandardSeid(ter Id  tid)->seid  stdSeid; 
TDBmaxLevel(terId  tid)->accessLevel  mal; 

FROM  udb : 

UDBvalidUserName(userName  un)->B00LEAN  b: 

UDBgetUser Id(userName  un)->userld  uid; 
UDBencryptedPw(user Id  uid)->encryptedPw  epw; 
UDBdefaultGroup(userId  uid)->groupId  gid; 

UDBmaxLevel (userid  uid)->accessLevel  mal: 
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46  VFUN 

47  VFUN 

48  VFUN 

49 

50 

51  VFUN 

52  VFUN 

53  VFUN 

54  VFUN 

55  VFUN 

56 
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57  FROM  gdb : 

58  VFUN  GDBvalldCr jupName( groupName  gn)->BOOLEAN  b; 

59  VFUN  GDBgetGroupId( groupName  gn)->groupId  gid; 

60  VFUN  GDBpwExists (groupld  gid )-> BOOLEAN  b; 

61  VFUN  GDBencryptedPw(groupId  gid)->encryptedPw  epw; 

62  VFUN  GDBmaxLevel (groupld  gid )->acce ssLevel  mal : 

63 

64  FROM  pfn: 

65  VFUN  PFNgetProcf’ssLeval ( )->STRUCT  OF(accessLevel  al;userld  owner; 

66  groupld  group)pal; 

67  OFUN  PFNsetProcessLevel(accessLevel  al;userld  newOwner ; croup Id  newGroup; 

68  INTEGER  newDa); 

69  OFUN  PFNstartUser (ter Id  tid;  userid  uid :  accessLevel  al); 

70  VFUN  PFNqueryAc cive( ter Id  tid ; accessLevel  al)->seid  pSeid; 

71  OFUN  PFNstrikeAllActiveShells(cerId  tid); 

72 

73  FROM  ffn: 

74  OFUN  FFNsetTerminalLevel ( terld  tid;accessLevel  al;userld  newOwner : 

75  groupld  newGroup ; INTEGER  newDa; 

76  VFUN  FFNgetTerr  inal  Level  ( ter  Id  ti  d  )->STRUCT_OF('accessLe'  el  al: 

77  userid  owner ; groupld  group ; INTEGER  da)tal; 

78 

79 

80  FUNCTIONS 

81 

82  OFUN  UAClogin( ter  Id  tid;  userName  un;  password  pw); 

83 

34  DEFINITIONS 

85  userid  uid  IS  UDBgetUserld(un) ; 

36 

87  EXCEPTIONS 

88  NEuacTerLoggedln:  "(FFNgetTerminalLevel (tid ) .owner-TDBd-faultOwner ) ; 

89  NEuacTerLocked:  TDBlocked(tid) ; 

90  NEuacBadLoginl :  ~UDBvalidUserName(un); 

91  NEuacBadLogin2:  ~(UDEencryptedPw(uid)*ENCrypt(pw)) : 

92 

93  EFFECTS 

94  EFFECTS_0F  FFN'setTeroinalLe  vel  ( tid  .ALCloginLevel , 

95  uid , UDBdefaul tGroup(uid ) , 600  ) ; 

96  EFFECTSOF  PFNsetProcessLevel (ALCloginLevel , uid , UDBdefa ultGroup(uid) ,?) ; 

97  EFFECTS _0F  PFNstartUser( tid , uid, ALCloginLevel); 

98 

99 
100 
101 
102 

103  OFUN  UAClogout( ter  Id  tid); 

104 

105  EFFECTS 

106  EFFECTS_OF  N_kill_all(TDBstandardSeid(tid)) ; 

107  EFFECTS _0F  PFNstrikeAllActiveShells( tid ); 

108  EFFECTS_0F  FFNsetTerminalLevel( tid .ALCgroundLevel ,TDBde  faultOvmer , 

109  TDBdefaultGroup.TDBdefaultDa) ; 

110  $( EFFECTS  OF  K_device_function  to  stty  the  terminal  back  to  its 

111  default  speed,  kill,  and  erase  characters) 

112  EFFECTS  OF  PFNsetProcessLevel (ALCgroundLevel ,?,?,?) ; 
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114 

115 

116  OFUN  UACchangeCroup(groupName  gn;  password  pw): 

117 

118  DEFINITIONS 

119  groupld  gld  IS  GDBgetGroupId(gn) : 

120 

.21  EXCEPTIONS 

122  NEuac  Bad  Group  :  ~GDBvalidGroupN’ame(gn) ; 

123  NEuac BadPw :  ~(CDBpwExists( gld )*>GDBencryptedPw( gid )*ENCvypt (pw) ) ; 

124  NEuac3alLevel :  ~ALCsetPerfflissible(PFNgetProcessLevel() ..il , 

125  GDBmaxLevel(gid)) ; 

126 

127  EFFECTS 

128  EFFECTSOF  PE Nse tProcessLe veil PFNget Pro cess Level ( ) . al , ? . gid . ?) : 

129 

130 

131  OFUN  UACchan ’eAccessLevel(terId  tid;  accessLevel  ral); 

132 

133  DEFINITIONS 

134  userid  uid  IS  PFNget ProcessLe vel ( ) .owner ; 

135  groupld  gid  IS  PFNgecProcessLevel () .group; 

136 

137  EXCEPTIONS 

138  NEuacBadLevell :  “(ALCse tPermissible(ral , SDBmaxLevelQ ) ) ; 

139  NEuacBadLevel2 :  ~(ALCsetPermissible(ral,TDBniaxLevel(tid))) ; 

140  NEuacBadLevel3 :  ~(ALCsetPermissible(ral .UDBmaxLevel (uid ))) ; 

141  NEuac BadLeve  14  :  ~(ALCsecPertnissible(ral,GDBniaxLevel(gid))); 

142 

143  EFFECTS 

144  EFFECTS_0F  PFNsetProcessLevel(ral ,?,?,?) ; 

145  EFFECTS_0F  FFNsetTer-ainalLevel (tid, ral ,?,?,?)  1 

146  LET  seid  p=PFNqueryAc.tive(tid,ral) 

147  IN  IF(p=  ?$ (OR  p  NOT  active))THEN  EFFECTSjOF  PFNstartJser(tid,uld,ral) 

148  ELSE  TRUE; 

149 

150 

151  END  MODULE 
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1  MODULE  udb  $(user  access  authentication  data  base) 

2 

3  TYPES 

4 

5  userid :seld; 

6  groupld : seid : 

7  userName:  {VECTOR_OF  CHAR  n  ILENGTH  (n»-l } ; 

8  encryptedPv:  {VECTOR_OF  CHAR  e I  LENGTH (e)-EKCepwLength } : 

9  accessLevel:  STRUCT_0F (INTEGER  securi tyLe vel , IntegrityLe vel; 

10  SET_OF  securityCat  sCatSet): 

11 
12 

13  EXTERNALREFS 

14 

15  FROM  ser. : 

16  seid. 'DESIGNATOR: 

17 

18  FROM  til  : 

19  securityCat : DESIGNATOR; 

20 

21  FROM  enr: 

22  INTEGER  ENCepwLt- ngth ; 

23 

24 

25  ASSERTIONS 

26 

27  FORALL  userNatne  x: 

28  CARDINALITY. {userid  uld IUDBloginName(uid )«x} )  <-  1: 

29  $(In  other  words,  unique  user  names  are  required) 

30 

31 

32  FUNCTIONS 

33 

34  $( - user  access  control  state - ) 

35 

36  VFUN  UDBIoginNarae(user Id  uid)->userName  n; 

37 

38  .  INITIALLY  n*?; 

39 

40 

41  VFUN  UDBencryptedPassword(user Id  uid)->encryptedPw  p; 

42 

43  INITIALLY  p-?; 

44 

45 

46  VFUN  UDBdefaul tGroup( userid  uid)->groupId  gid: 

47 

48  INITIALLY  gid*?; 

49 

50 

31  VFUN  UDBloginDlrectory(userId  uld )->VECTOR_OF  CHAR  dNam*  ; 

52 

53  INITIALLY  dName-?; 

34 

55 

56  VFUN  UBDinitialShelKuserld  uid)->VECTOR  OF  CHAR  sNane; 
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57 

58 

59 

60 
61 
62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 


INITIALLY  sName-?; 

VFUN  UDBmaxLevel(userId  uld)->accessLevel  1; 
INITIALLY  1-?; 


$( -  db  extraction  functions  - 

VF'JN  LT)BvalidUserName(userName  un)->BOOLEAN  b; 
DERIVATION 

EXISTS  userid  x:UDBlogin>Iame(x)“un; 


74  VFUN  UDBgetl'serId(userName  un)->userld  uid; 

75 

76  EXCEPTIONS 

77  NEudbBadName :  ~UDBvalidUserName(un) ; 

78 

79  DERIVATION 

30  SOME  userid  x  |lrDBloginName(x)  *  un ; 

31 
82 

83  END  MODULE 


) 
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1 

2  $(" 

3 

4 

5 

6 
7 
3 

9  ") 
10 


MODULE 


CONTENTS 

TYPE 

LAST  CHANGED: 


udm. specs  (Version  1.5,14:55:05) 

Module  Name  (udm. specs) 

File  Name  (/kr/sunix/specs/nksr/s .udm. specs) 
directory  manager 
SPECIAL .  sped  flea t  Ions 
11/21/80,14:55:05 


11  MODULE  udm 

12 

13  TYPES 

14  dirName:  VEC1OFJ0F  CHAR: 

15  path:  VECTOR  F  dirName; 

16  nonDisType:  3TRt'CT_0F( 

17  INTEGER  securityLevel :  SET  OF  securltyCat  securityCatS ; 

18  INTEGER  lntegri cyLe vel ;  SET_0F  integrltyCit  IntegrltyCatS ) : 

19  $(lntegrltyCat  is  typically  the  null  set) 

20  daType:  SET  OF  daMode: 

21  modeStruct:  STRrCT_0F( daType  ownerMode.  groupMode,  allM<  ie); 

22  tiiStruct:  STRUCT _0F(nonDisType  nd : 

23  modeStruct  da;  INTEGER  owner,  group;  SET  IF  privType  prlv); 

24 


25 

26  PARAMETERS 

27  seid  ROOTseid  $(root  of  the  directory  system), 

28  sameNspSeid,  $(special  seid  whose  nsp  component  if  "sameNsp" 

29  to  indicate  whether  or  not  a  file  or  directory  x 

50  has  been  mounted,  x  has  been  mounted  iff 

31  its  nsp  component  is  not  "sameNsp".) 

32  zeroFive,  $(special  seid  whose  index  field  corresponds 

33  to  the  implementation  value  <0,5>  which  represents 

34  mounted  files  or  directories.  This  par.  meter  is  used 

35  by  the  VFUN  derivedDirectory. ) 

36  slashTmpSeid, 

37 

38 

39 

40 

41 

42  usersTmpSeid ; 

43 

44 

45 

46 

47 

48 

49 

50  DEFINITIONS 

51  BOOLEAN  mounr.Equiv(seid  sl,s2)  IS 

52  si  *  s2  OR 

53  (SENseidlndex(sl)  *  SENseidIndex(s2) 

54  AND 

55  SENseidNspCs t )  ■  SENseidNsp(sameNspSeld )) ; 

56  $("True  iff  s2  ■  si  or  s2  has  been  mounted  on  si.  mountEquiv 


$("The  seid  of  the  directory  /trp. 

This  seid  could  be  defined  as 
simpPath Interpret (pSeid , ROOTseid , <“ tmp">) , 
where  simpPathlnterpret  is  obtained  from 
pathlnterpret  (below)  by  using  directory 
instead  of  derivedDirectory") 

3("  The  seid  of  the  user's  unique  tmp  directory, 
which  exists  under  /tmp.  users'mpSeid  could  be 
defined  as  simpPathInterpret(pSeid, ROOTseid , 
<"tmp" , ”uniqueName">) ,  where  simpPathlnterpret 
is  obtained  from  pathlnterpret  by  using 
directory  instead  of  derived Directory.") 
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57  is  used  in  existsPath  (below).  Basic  idea  is  that  IF 

58  a  sequence  of  unmounts  were  to  be  done,  then  there 

59  would  be  a  "direct"  path  in  the  definition  of  existsPath . “ ) 

60 

61  BOOLEAN  exist sPath(seid  start, stop)  IS 


62 

(EXISTS  INTEGER  n  1 

n  >  1: 

63 

(EXISTS  VEGT0RJDF 

dirName  d  1  LENGTH (d)  *  n-1 

1  ..  n-1}  : 

64 

AND  (FORALL  INTEGER  jl  j  INSET 

65 

NOT  d[j]  INSET  '.."})  : 

66 

(ex:  -rs  veciuR 

_0F  seld  s  I  (LENGTH (s)  «  n 

67 

AND  s [ 1 }  =  start 

68 

AND  s[nj  =  stop)  : 

69 

( EORALL  INTEGER  i|  i  INSET  {1  ..  n-1 }  : 

70 

mountEqui v( director 

v(s[i),d[i]),s{i+l])) 

71 

))): 

72 

73  seid  realDirseid  dirSeid;  dirName  name)  IS 

74  IF  dirSeid  *  usersTmpSeid  AND  name  ”  THEN 

75  slashTnDSeid 

76  ELSE  IF  dirSeid  *  slashTmpSeid  AND  NOT  name  INSET  THEN 

77  usersTmpSeid 

78  ELSE 

79  dirSeid: 

80 

81  seid  pathlnt-rpret (seid  pSeid , dirSeid;  path  p) 

82  $ (  'This  definition,  in  conjunction  with  the  auxilliary  one  pil 

33  given  below,  essentially  tries  to  work  its  way  down  a  path 

34  p,  starting  at  node  dirSeid, 

35  a  node  at  a  time,  returning  as  a  value  the  last  node 

36  encountered.  Various  exceptions  must  be  met  successfully 

37  before  moving  from  one  node  to  the  next.  The  notion  of  a  path 

88  as  used  in  these  specs  as  an  abstraction  of  the  standard  Unix 

89  notion  of  a  path.  For  example,  the  path  /a/b/c  would  be 

90  represented  simply  as  the  sequence  of  names  a  b  c. 

91  ") 

92  IS 

93  IF  isDirec  tory( dirSeid)  THEN 

94  $(Startlng  node  must  be  directory  to  continue  down  path) 

95  IF  ( 

96  SMXdap(pSeid, dirSeid, {daRead}) 

97  OR 

98  SMXdap( pSeid , dirSeid , {daExecute }) 

99  ) 

100  AND 

101  SMXf low(pSeid, dirSeid, {daRead}) 

102  $(Must  have  discretionary  read  or  execute  permission, 

103  and  must  have  mandatory  read  flow  to  continue  down  path) 

104  THEN 

105  IF  LENGTH(p)  >  0  THEN 

106  pil(pSeid, dirSeid, p)  $(Start  recursive  call  to  move 

107  down  the  path) 

108  ELSE  $(path  is  of  length  0,  so  return  dirSeid) 

109  dirSeid 

110  ELSE  S ( flow  violated) 

111  ? 

112  ELSE  $(starting  node  is  not  a  directory) 
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113  ? 

114  : 

115 

116 

117  seld  pil(seid  pSeid .dirSeid ;  path  p) 

118  $(An  auxilliary  definition  used  by  pathlnterpret) 

119  $(We  know  at  che  beginning  of  each  recursive  call  that 

120  dirSeid  is  a  directory  to  which  pSeid  has  access,  and  that 

121  path  p  is  non-null.) 

122  IS 


123 

124 

125 
12  6 

127 

128 

129 

130 

131 

132 

133 

134 

135 

136 

137 

138 

139 

140 

141 

142 

143 

144 
14  5 

146 

147 

148 

149 
1  50 
151 


IF  derivedDirectory(dirSeid,p[ 1  ])  “=»  ?  THEN7 
$(There  Bust  be  a  well-defined 
next  node  along  the  path.) 

IF  ( 

SMXdapC pSeid , derivedDi rector y( dirSeid , p [ 1 ]) ,  { da Read } ) 

OR 

SMXdap( pSeid , derivedDirec tor y( dirSeid . p[ 1 ] ) ,  {daExecute } ) 

) 

AID 

SMXf low( pSeid , derivedDirec  tor y( dirSeid  p[ 1 ) ) , {da Read} ) 
S(Must  have  discretionary  read  or  execute  :  ermission , 

and  must  have  mandatory  read  flow  to  continue  down  path) 

THEN 

IF  LENCTH(p)  >  1  THEN 

IF  isDirectory(derivedDirectory(dirSeid ,p[ 1 ] ))  "HEN 

S(basic  recursion:  move  one  node  down  the  path) 
pil (pSeid, derivedDirect or y( dirSeid, p  f 1  ]) , 

VECTOR (FOR  i  FROM  2  TO  LENGTH (p):  p[i])) 

ELSE  $ (There  are  at  least  two  more  nodes  along  the  path, 
but  the  next  one  is  not  a  directory,  so  r 'turn  ?) 

7 

ELSE  S(The  next  node  is  the  last  one  in  the  path,  so  return  it) 
der ivedDirectory(dirSeid ,p[l  ]) 

ELSE  $(Flow  or  dap  violations  encountered) 

7 

ELSE  $(There  is  not  a  well-defined  next  node  along  the  path) 

i 


152 

153  EXTERN ACRE FS 

154 


155  FROM  smx: 

156  seid:  DESIGNATOR; 

157  secureEntityType :  {tFile,  tDevice,  tTerminal,  tProcess ,  tSegment,  tSubtype, 

158  tExtent,  tNull}; 

159  privType:  f 

160  privFileUpdateStatus ,  privLink,  privLockSeg, 

161  privModifyPri v,  privMount, 

62  privSetFileLevel,  privSetSegProcLevel , 

163  pri vStickySeg ,  privTerminalLock, 

164  privViolSimpSecurity,  privViolStarSecurity , 

165  priWiolSimplntegrity,  privViolStarlntegrity, 

166  privViolDiscr Access,  privSignal,  privWalkPTable , 

167  privHalt,  pri vKemelCall ,  privVioiCompartments , 

168  privRealizeExec Permissions } ; 
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169 

170  daMode:  {daXeid,  daWrite,  daExecute}; 

171  securityCat:  DESIGNATOR: 

172  integrityCat :  DESIGNATOR : 

173  domainType:  {userDomain,  supervisor Domain } : 

174 

175  VFUN  Tlllnfol seid  s)  ->  tliStruct  st; 

176  VFUN  SMXflow.se id  pSeid,  oSeld;  daType  da)  ->  BOOLEAN  b-  S(SMXflow) 

177  VFUN  SMXdapf seid  pSeid,  oSeld;  daType  da)  ->  BOOLEAN  b:  $(SMXdap) 

178  VFUN  SENseidl'j['(seid  anySeld)  ->  INTEGER  nsp:  $(SENseidNsp) 

179  VFUN  SENseid Incex(seid  anySeld)  ->  INTEGER  index; 

180  VFUN  SENmakeSoid(seid  exampleSeid ;  INTEGER  Index)  ->  seid  rSeid; 

181  VFUN  SENseid7vpe(seid  s)  ->  secureEntityType  set; 

182 
183 

134  ASSERTIONS 

185  $(The  following  assertions  deal  with  the  basic  tree  structue 

186  of  directories.) 

187 

188  $(ASSERTION  1) 

189  FORALL  seid  s  ;  isDirectory(s) :  director y( s , )  ”  s; 

190  $(Each  directory  links  to  itself  via  ”.“) 

191 

192  $(ASSERTION  21 

193  FORALL  seid  parentSeid;  seid  childSeid  ! 

194  (isDirectory(parentSeid) 

195  AND  isDirectory(childSeid) 

;96  AND  parent(childSeid)  *  parentSeid): 

197  ((EXISTS  dlrName  name:  directory(parentSeid,name) 

198  -  childSeid) 

199  AND  directorv(childSeid, ". . ")  *  parentSeid); 

.200  S(Whenever  the  ghost  variable  parent  points  from  child  to  parent, 

201  there  is  a  real  link  from  parent  to  child  via  some  name,  and  there 

202  is  a  real  link  from  child  to  parent  via  ’’••") 

203 

204 

205  $ (ASSERTION  3) 

206  FORALL  seid  s  I  isDirectory( s ) :  existsPath(R00Tseid , s) ; 

207  $(Every  directory  is  reachable  starting  from  the  root.) 

208  $(The  only  link  to  the  root  is  via  the  root  itself.) 

209 

210  $( ASSERTION  4) 

211  FORALL  seid  si; seid  s2  I 


212  (isDirectory(sl)  AND  isDirectory(s2)  AND  sl~“  s2): 

213  (NOT  (existsPath(sl,s2)  AND  existsPath(s2 , s 1 ) )) 

214  $(No  cycles  exist  between  distinct  nodes.) 

215 

216 

217 

218  FUNCTION’S 

219 

220  $( - VFUNS - ) 

221 

222  VFUN  directory(seid  dirSeid;  dirName  name)  ->  seid  ansSeid; 

223  HIDDEN; 

.224  INITIALLY 
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225  ansSeid  » 

226  (IF  (dirSeid  -  ROOTseid  AND  name  INSET  THEN 

227  ROOTseid 

228  ELSE 

229  ?); 

230  $  (Initialized  by  mkDir;  updated  by  mkEntry ,  rvEntry :  finalized  by  remove.) 

231 

232  VFUN  derivedDi rectory(seid  dirSeid;  dirName  name)  ->  seid  ansSeid: 

233  $(For  certain  functions,  such  as  path  interpret,  der i vedDirectory 

234  rather  than  directory  is  utilized,  directory  corresponds  to 

235  the  implementation-visible  table,  whereas  der ivedDirectory 

236  returns  a  run-time  computable  value  based  on  this  table.) 

23  7  DEFINITION’S 

23  8 

239  seid  s  IS  d irectory( realDir (dirSeid , name) , name) ; 

240 

241  EXCEPTIONS 

242  badLogic:  FALSE;  $(Placeholder  for  exceptions) 

2+3  DERIVATION 

2+4  (IF  s  '*?  THEN 

245  IF  SENsei INsp(s)  =  SENseidNsp(sameNspSeid)  THEN 

246  SENmakeSeid (rea IDir (di rSeid , name) , SENseidIndex(s ) ) 

247  ELSE  IF  £/.NseidType(s)  =  tFile  THEN  $(mount  processing) 

248  SENmakeSeid (s ,SENseidIndex(zeroFive)) 

249  ELSE  S(non-file  type  in  directory.  This  had  better  be 

250  the  last  component  of  a  path) 

251  s 

252  ELSE 

253  ? 

254  ); 

255 

256 

257  VFUN  isDirector y(seid  dirSeid)  ->  BOOLEAN  b: 

258  HIDDEN; 

259  INITIALLY 

260  b  -  (dirSeid  =>  ROOTseid); 

261  $(Initiali zed  by  mkDir;  finalized  by  remove.! 

262 

263  VFUN  parent(seid  dirSeid)  ->  seid  s; 

264  HIDDEN; 

265  INITIALLY 

266  s  -  (IF  dirSeid  -  ROOTseid  THEN  ROOTseid  ELSE  ?>: 

267  $(Ghost  variable  corresponding  to  the  double-dot  entry  in  each 

268  directory.  Initialized  by  mkDir;  finalized  by  remove.) 

269 

270 

271  $( - OFUNS - ) 

272 

273  OFUN  mkEntry(seid  pdirSeid,  eSeid;  dirName  namel)[seid  nSeid] ; 

274  SC’Link  from  (dirSeid , namel )  to  eSeid.  eSeid  must  not  be 

275  a  directory  -  if  it  is,  the  OFUN  mkDir  is  used  instead.”) 

276 

277  DEFINITIONS 

278  seid  dirSeid  IS  rea lDir(pdirSeid , namel); 

279 

230  EXCEPTIONS 
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281  badFlow:  N'T  isDireccory(dirSeid)  OR  NOT  SMXflow(pSeid,dirSeid, 

282  {daRead , daWrite } ) ; 

283  badDap:  NOT  SMXdap(pSeid, dirSeid , {daExecute .daWrite }) ; 

284  NotSameFileSystem:  SENseidNsp(dirSeid)  “■  SENseldNsp(eSeld) ; 

285  badarg:  isDirectory(eSeid); 

286  nameExists:  directory(dirSeid, namel)”*  ?; 

287  RESOURCEErlRCR; 

288 

239  EFFECTS 

290  'directory! dirSeid .namel)  *  eSeld; 

291 

292 

293  OFUN  mount(scid  pdlrSeid,  nspSeld:  dirName  name)  [seid  pSeid, parentpSeid] ; 

294  S("mount  a  new  extent  on  directory(dirSeid,name) ,  by  replacing 

295  its  nsp  field  with  that  of  nspSeid.") 

296  S(The  object  being  mounted  can  only  be  a  certified  KSOS  file  system; 

297  this  is  enforced  by  the  mount  CPC) 

298  $("The  additional  implicit  parameter  parentpSeid  is  the  seid 

299  of  the  parent  process  of  pSeid.  It  is  derivable  from  pSeid  by 

300  bringing  up  additional  state  information  from  the  kernel  specs, 

301  but  for  simplicity  here  is  given  in  this  form.  Its  use  here 

302  is  in  the  notMountpriv  exception  below”) 

303 

304  DEFINITIONS 

305  seid  dirSeid  IS  realDirfpdirSeid,  name); 

306  seid  d  IS  directory(dirSeid,name)  ; 

307 

308  EXCEPTIONS 

309  badFlow:  NOT  isDirectory(dirSeid )  OR  NOT  SMXflow(pSeid, dirSeid , 

310  {daRead .daWrite }) ; 

311  badDap;  NOT  SMXdap(pSeid , dirSeid , {daRead , daWrite} ) : 

312  badName:  d irectory(dirSeid , name)  =  ?; 

313  notMountpriv:  NOT  privMount  INSET  Tllinfo(parentpSeid) .priv; 

314  cannotMountHere :  SENseidNsp(sameNspSeid)  ~=  SENseidNsp(d)  ; 

315  notFileType:  SENseidType (d)  ~=tFile;  $(The  object  upon  which  we  are 

316  mounting  must  be  a  file,  which  includes 

317  directories) 

318 

319  EFFECTS  » 

320  'directory ( dirSeid .name)  ■  SENmakeSeid(nspSeid, 

321  SENseidIndex( directory( dirSeid, name))) ; 

322 

323  OFUN  unmountfseid  pdlrSeid;  dirName  name)  [seid  pSeid, parentpSeid] ; 

324  SC'Undo  the  mount  operation  by  restoring  the  nsp  field  of 

325  directory(dirSeid.name)  to  the  value  saneNsp.") 

326  SC'The  additional  implicit  parameter  parentpSeid  is  the  seid 

327  of  the  parent  process  of  pSeid.  It  is  derivable  from  pSeid  by 

328  bringing  up  additional  state  information  from  the  kernel  specs, 

329  but  for  simplicity  here  is  given  in  this  form.  Its  use  here 

330  is  in  the  notMountpriv  exception  below") 

331 

332  DEFINITIONS 

333  seid  dirSeid  IS  realDir (dirSeid , name) ; 

334 

335  EXCEPTIONS 

336  badFlow:  NOT  isDirectory(dirSeid)  OR  NOT  SMXflow(pSeid, dirSeid, 
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337  {daRead, daWrite } ) ; 

338  badDap:  NOT  SMXdap(pSeid  .dirSeid ,  {daRead  ,  daWrite }) ; 

339  badNarae:  dlrec tory( dirSeid , name)  *  ?; 

340  notMountpriv :  NOT  prlvMount  INSET  Til inf o(parentpSeid ) .pri v; 

341 

342  EFFECTS 

343  'directory! dirSeid, name)  =  SENmakeSeld(sameNspSeid, 

344  SENse Id Index (dlrec tor y(dtrSeld , name) ) ) ; 

345 
3->6 

347  OF  UN  mkDir(seid  pparentSeld:  dlrName  namel)  [seid  pSeid] ; 

348  $(Create  a  new  directory  as  a  child  of  parentSeid,  linking  from 

349  parent  to  child  via  namel.  The  child  seid  is  defined  below. 

350  Initialize  che  new  directory  with  dot  and  double-dot  entries,  and 

351  maintain  invariance  of  tree  assertions.) 

352 

353  DEFINITIONS 

354  seid  parentSeid  IS  realDir(pparentSeid , namel ) ; 

355  seid  childSeid  IS  SOME  seid  s  I 

356  Tllinfo(s)  =?  AND  SENseidNsp(s )  -  SENseidNsp(parentSeid); 

357 

358  EXCEPTIONS 

359  badFlow:  NOT  isDirectory(parentSeid)  OR  NOT  SMXf low(pSeid , parentSeid , 

360  { daRead , daWrite }) : 

361  badDap:  MOT  SMXdap(pSeid , parent Seid , {daExecute , daWrite }) ; 

362  badSeid:  childSeid  *?; 

363  nameExists.  d irectory(parentSeid , namel)  ?: 

364 

365  EFFECTS 

366  'directorylparentSeid, namel)*  childSeid: 

367  'TIIinfo( child Seid)*  Tllinfo(pSeid) ; 

368  'directory! childSeid )■  childSeid; 

369  'directory! childSeid,". . ”)“  parentSeid; 

370  'parent(chi  IcSeid)  *  parentSeid; 

371  'isDirector v( childSeid)  *  TRUE; 

372 

373 

374  OF UN  reraove(seid  pparentSeld;  dirName  namel )[ seid  pSeid |; 

375  S( "Unlink  the  (parentSeid,  namel)  entry.  If  the  child  is  a  directory, 

376  it  must  be  empty,  and  pass  da  checks.”) 

377 

378  DEFINITIONS 

379  seid  parentSeid  IS  realDir (pparentSeld , namel ) ; 

380  seid  aSeid  IS  directory(parentSeid , namel ) ; 

381 

382  EXCEPTIONS 

383  badFlow:  NOT  isDirectory(parentSeid)  OR  NOT  SMXf low(pSeid , parentSeid , 

384  {daRead, daWrite}); 

385  badDap:  NOT  SMXdap(pSeid , parent Seid , {daExecute , daWrite }) : 

336  badName:  iirectory(parentSeid, namel)*?: 

387  badDap2:  isDirectory(aSeid )  AND  NOT  SMXdap(pSei d , aSei d, {daRead .daWrite }) : 

388  notEmpty:  isDirectory(aSeid)  AND  (EXISTS  dirName  name2  I 

389  NOT  name2  INSET  { 

">90  directory(aSeid , name2)~*?) : 

391 

392  EFFECTS 
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393  'direc  Cory  ( parentSe  i<f ,  nanel )  -*  ?; 

394  isDlrectory(aSeid)  ->  'directory(aSeid, ? 

395  AND  'directory(aSeid, ” . . -  ? 

396  AND  'isDirectory(aSeid)  *  FALSE 

397  AND  'parent(aSeld)  “  ?; 

398 

399  $(The  following  OFUNs ,  piRemove.piMkEntry,  piLocate,  an!  plChangeDir, 

400  are  provided  for  the  KSOS  emulator.  Thetr  purpose  here  is  simply 

401  to  let  the  caller  know  whether  an  exception  would  h  -  r  ■  u'l't  ’>/ 

-•02  a  call  to  remove,  mkEntry,  locate,  and  changeDir  respectively. 

403  Thus,  in  the  OFUNs  below,  the  EFFECTS  sectir 
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